Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Java 9: The State of the Module System

openjdk.java.net

Post reply on HN
Print view View original

51–59 of 59 posts

Re: Java 9: The State of the Module System

#51

Post by aabbccdd »

skrebbel wrote: post #48
aabbccdd wrote: post #46

Earlier quoted context omitted.

Are there any horrible hacks needed for Ruby to cope with dependencies? Is this something new or you're just ranting?

My experience with this is a bit dated so maybe they fixed it since, but here goes: Gems are installed globally on your system. You need something like RVM to work around this, but oops, RVM doesn't work on Windows and one of your devs uses that. There's a 3-year old tutorial about how you can get it to work with cygwin, but that doesn't work well with your favourite Ruby IDE, and the list goes on. You want to deploy…

Seems like you have never used bundler with .bundle/config file containing BUNDLE_PATH: vendor/bundle (or other subdirectory). That's it.

Re: Java 9: The State of the Module System

#52

Post by EdSharkey »

skrebbel wrote: post #45

The cool thing is that compared to many languages/platforms, Java already has an excellent module system. Just look at the horrible hacks you have to go through in C++, Ruby or Python to manage multiple projects written in different versions of the language or with different versions of dependencies are just ridiculous, especially if you're developing on multiple platforms. Oh, you want to deploy it too? Have fun. Le…

Practically speaking, Maven (the executable tool) and pom.xml (the language) create a hot dependency mess when projects get past the toy stage. Maven makes most simple things impossible and a few challenges trivial. "Hamstrung" is the word that comes to mind. Coupling a declarative, own-the-world, XML programming language with innumerable slap-dash/poorly maintained plugins is the pits.

All that said, maven repositories and the groupId:artifactId:version:type:classifier organization of modules are really genius. As you say, this genius shines in IDE's where, as just one example, you get nice binary/source .jar distributions automatically downloaded to your local repo. Having an IDE's debugger be able to seamlessly and accurately step through 1st party java sources and 3rd party source .jar sources is always so impressive to me.

Gradle (and Ivy before it) help paper over the pain and expose the good parts of the maven ecosystem. I have some gripes with Gradle, but after seeing it in action (and now that IDE's can grok its project configs) I'm so happy to be ditching maven/plugins and hand-written pom's for the most part.

Java needs a holistic dependency management/dependency injection/artifact repository/publishing workflow rethink where well-defined concepts like semver are enforced in the version numbering scheme, making it easier to express "safe" legal version ranges in transitive dependencies.

Re: Java 9: The State of the Module System

#54

Post by pjmlp »

uxcn wrote: post #44
pjmlp wrote: post #42

Earlier quoted context omitted.

> Is there an actual JSR for reified generics? I was under the impression that would generally break VM compatibility. Not yet. But it might happen, it depends how value types get implemented. Check "New Bytecodes, New Objects", "Adventures on the Road to Valhalla": http://www.oracle.com/technetwork/java/javase/community/jlss... > I have a hard time believing Google will stop supporting Java on Android Of course they…

Interesting, thanks for the links. Honestly, I tend to avoid writing Java in favor of native languages at this point largely because of latency requirements. I still wonder where code sharing outweighs the type cast overhead for most JVMs though. > It doesn't have any official support from the Android team. Go on Android definitely seems to be in its infancy.

Just as extra info in case you aren't aware, Java is also compiled directly native code on Android as of 5.0.

https://source.android.com/devices/tech/dalvik/index.html#AO...

And apparently Oracle is finally joining the third party JVMs by adding AOT support to the reference JDK, but it might only come after Java 10.

This together with the upcoming value types and JNI replacement, might eventually close the gap with the alternatives.

Not being a Java zealot, as a polyglot developer I use a bit of everything, just spreading the word.

Re: Java 9: The State of the Module System

#55

Post by namelezz »

uxcn wrote: post #41
pjmlp wrote: post #38

Yet another feature that Android devs won't get. By the time Java 10 gets out, they can see how libraries that make use of modules, reified generics, value types, GPGPU integration, JIT plugins are out of reach. Worse even, having library devs writing two versions of their libraries. Google's fork of Java is leading to a Python 2 - 3 scenario.

Is there an actual JSR for reified generics? I was under the impression that would generally break VM compatibility. I have a hard time believing Google will stop supporting Java on Android, especially considering how widely they support it for other various platforms. I do know Go support for Android was recently released though.

I think Google probably is looking at Kotlin for Java replacement on Android.

Re: Java 9: The State of the Module System

#56

Post by pron »

namelezz wrote: post #55
uxcn wrote: post #41

Earlier quoted context omitted.

Is there an actual JSR for reified generics? I was under the impression that would generally break VM compatibility. I have a hard time believing Google will stop supporting Java on Android, especially considering how widely they support it for other various platforms. I do know Go support for Android was recently released though.

I think Google probably is looking at Kotlin for Java replacement on Android.

That is completely orthogonal. Kotlin works on top of the Java ecosystem, and therefore enjoys the same capabilities and libraries enjoyed by Java -- which Android users won't get even if they use Kotlin. Kotlin code that uses Java libraries that use features that are not available on Andorid won't work on Android.

Re: Java 9: The State of the Module System

#57

Post by vorg »

EdSharkey wrote: post #52
skrebbel wrote: post #45

The cool thing is that compared to many languages/platforms, Java already has an excellent module system. Just look at the horrible hacks you have to go through in C++, Ruby or Python to manage multiple projects written in different versions of the language or with different versions of dependencies are just ridiculous, especially if you're developing on multiple platforms. Oh, you want to deploy it too? Have fun. Le…

Practically speaking, Maven (the executable tool) and pom.xml (the language) create a hot dependency mess when projects get past the toy stage. Maven makes most simple things impossible and a few challenges trivial. "Hamstrung" is the word that comes to mind. Coupling a declarative, own-the-world, XML programming language with innumerable slap-dash/poorly maintained plugins is the pits. All that said, maven repositor…

Because Maven (the tool) offers XML as the language, we can put any other language atop it, e.g. with https://github.com/takari/polyglot-maven we can use Clojure, Groovy, Ruby, or Scala as the language. Gradle offers only Groovy, nothing else, so we don't have any choice over how to interact with the build API.

Re: Java 9: The State of the Module System

#58

Post by LoneWolf »

EdSharkey wrote: post #52
skrebbel wrote: post #45

The cool thing is that compared to many languages/platforms, Java already has an excellent module system. Just look at the horrible hacks you have to go through in C++, Ruby or Python to manage multiple projects written in different versions of the language or with different versions of dependencies are just ridiculous, especially if you're developing on multiple platforms. Oh, you want to deploy it too? Have fun. Le…

Practically speaking, Maven (the executable tool) and pom.xml (the language) create a hot dependency mess when projects get past the toy stage. Maven makes most simple things impossible and a few challenges trivial. "Hamstrung" is the word that comes to mind. Coupling a declarative, own-the-world, XML programming language with innumerable slap-dash/poorly maintained plugins is the pits. All that said, maven repositor…

I admit that maven on large projects can lead to some dependency problems, while not the final solution I found that Maven Enforcer Plugin[1] helps to reduce this mess, makes it harder to keep the dependencies because sometimes you have to exclude them everywhere and add your own by hand, but I don't see any better alternative, APIs change.

[1] http://maven.apache.org/enforcer/maven-enforcer-plugin/

Re: Java 9: The State of the Module System

#59

Post by dj-wonk »

EdSharkey wrote: post #52
skrebbel wrote: post #45

The cool thing is that compared to many languages/platforms, Java already has an excellent module system. Just look at the horrible hacks you have to go through in C++, Ruby or Python to manage multiple projects written in different versions of the language or with different versions of dependencies are just ridiculous, especially if you're developing on multiple platforms. Oh, you want to deploy it too? Have fun. Le…

Practically speaking, Maven (the executable tool) and pom.xml (the language) create a hot dependency mess when projects get past the toy stage. Maven makes most simple things impossible and a few challenges trivial. "Hamstrung" is the word that comes to mind. Coupling a declarative, own-the-world, XML programming language with innumerable slap-dash/poorly maintained plugins is the pits. All that said, maven repositor…

After I first read your last paragraph, I wondered "how might you want to see semantic versioning get enforced?" ... but I think you are instead referring to the lack of version number ranges in Maven?
Post reply on HN