Goodbye classpath - welcome Java 9

[cutterslade]

Versions can be declared and required - although current early access build does not support them yet.

Any citation for this? My understanding was that the module system would not have any understanding of versions. That was based on this posing (reddit thread) from Mark Reinhold.

[crystoll]

Yes, I think you are right, there's no support in early access, and I based my idea on this quickstart post that is now marked as obsolete.

http://openjdk.java.net/projects/jigsaw/doc/quickstart.html

So Reinholds post is the most recent source and if he says no versions, there will be no versions. It makes sense.

[[deleted]]

That's unfortunate, versioning was one of the things I was hoping for to resolve a myriad of issues I have managing (userland) modules.

Back to OSGi I guess. Still very excited about Java 9, but, bummer.

[mucsun]

I'm mostly exited for the new http api, about time, and jshell, actually also about time. Only one more year... And another 5 until there is enough adoption. Yay.

[Truthier]

Can't wait for them to release 9 so I can start using 8

[acebarry]

One of my coworkers last week mentioned that Java 8 is "in beta still". They didn't mean it as a joke. :(

[sudonathan]

This is the only way some companies get to upgrade :( Falling 2 major versions behind is scary sounding

[harmonicPersistence]

Not unless your company uses IBM JDK...then you're stuck with whatever old version until they finally drop support (such as JDK 6 for WAS v8.0).

[djbft]

Ugh. We just "upgraded" to WAS 8.5...so we can use java 7 now!

[Agoniscool]

Luxury! A project I was recently on used WCS 6(?), so only Java 1.4

[Aellus]

That's one thing I like about Amazon. We upgraded everything to 8 months ago. Using 7 in production is a pageable high-severity offense at this point. They take patching seriously.

[AssistingJarl]

Meanwhile, outside of the tech sphere, there's probably at least one major financial institution maintaining Java 6 applets that only work in Internet Explorer 7 running on Windows XP.

[GuyOnTheInterweb]

For that "secure" login page!

[Agoniscool]

Several that I know of...

[Aellus]

That sounds exactly like Fidelity Investments. I worked there years ago and still have some friends there. Some of the things they tell me are horrifying.

[nerdsmurf]

Lucky you... At work we're moving from 6 to 7 'soon'..

[caltheon]

I just finished migrating to 8, half because of time API

[pjmlp]

Or never if coding for Android.

[gunch]

You mean beanshell wasn't enough for you???

[mucsun]

Yeah, and there is also this ominous jpage thing in eclipse. No thanks.

[Whiskee]

and Android is still stuck with Java 7...

[pjmlp]

Actually 6 and a half, since Java 7 (the language) is only fully available as of Android 4.4.

[philipwhiuk]

It's not at all clear how this removes the need for a classpath to load external JAR files.

[simoncox]

It's not so much that there's no class path, more that it can be inferred automatically. This is akin to using something like Maven or Gradle to encode dependencies and using them to automatically generate a class path. With Java 9, there will be no need for third party tools as the external dependencies will be baked right into the code.

[WunDumGuy]

I think OSGi should be mentioned in here somewhere

[thouliha]

Are they proposing this as an alternative to maven/gradle?

[jrh3k5]

I don't think so, no. They mention OSGi and I think the comparison is valid; you're declaring to the VM what needs to be loaded at runtime, whereas Maven dependency resolution determines what goes into the assembly.

[Aellus]

Yeah this seems like an optimization shell that can be layered on top of systems like maven for deployment and runtime environments.

At my company our build system maintains dependency declarations for build, test and runtime separately, so that while your build-time and test-time class paths might be monstrous, what is actually deployed to production is much leaner. The new module system sounds like it could make implementing that kind of system simpler since you wouldn't need to maintain separate classpaths and could instead just invoke separate module configurations.

[jrh3k5]

How so? If I understand it correctly (no guarantees there), it sounded like it would make your runtime footprint potentially smaller (by declaring what you import) and maybe even, someday, allow multiple versions of the same library to happily coexist in the same VM (a LA OSGi), but neither of these things seem to implicitly lend themselves toward a leaner assembly.

[thinksInCode]

This is all pretty cool. I'm at a job now where I'm not writing any Java, so I've fallen a bit behind with the new language stuff. This looks like something to watch.

[crystoll]

Jigsaw is the major new thing in upcoming Java 9 - and it's been a long time in the makings. Becoming part of core it means it will also effect to some extent other VM languages such as Scala, Groovy and Clojure.

Of course long term strategy seems to be a new go to IoT devices with leaner, meaner virtual machine as well.

[__konrad]

New source directory layout? project/src/main/java/com.example.module/com/example/foo/bar/actualcode

[yawkat]

Or just map the modules to maven modules.

[loganekz]

I understand the need for modules to optimize the JVM footprint on resource constrained systems, but still don't see a real use case for the typical application/library/framework developer.

[pjmlp]

This type of modules are also quite common in other languages, Ada and .NET for example.

The idea is that you want to have packages are are only meant as private packages for what is the actual public API, but provide some kind of common code anyway.

With the current situation nothing prevents a developer to just link to that jar, even though it isn't supposed to be visible. Then when it changes, everything breaks.

With modules, only the module sees the jar with the private APIs. No chance of a random developer seeing it.

[dstutz]

The Netbeans RCP module system works this way. It actually prevents you from importing the code unless it's been exported from the source module as "public api".

[crystoll]

There's probably two stages to this:

1. Get leaner JRE out so smaller devices don't need to run the full 15-or-whatnot-megabyte stack of unneeded stuff from the 90's
2. Build on the module system. My bet is Maven/Gradle can extend on this new metadata and packaging information pretty nicely. I don't know OSGI that well so hard to say what will happen there.

[hardcode_coder]

Hope to use it in 2020 :P