Having said that, can some ELI5 what the module hubbub is about? I've mostly been ignoring it but now I'm curious, but as a non-Java programmer I'm not up on the debate.
Having said that, can some ELI5 what the module hubbub is about? I've mostly been ignoring it but now I'm curious, but as a non-Java programmer I'm not up on the debate.
Today, to run a hello world app, you have to have the entire Java SE platform on disk, including GUI code, XML parsing, CORBA, a MIDI player, etc. A lot of that code is itself written in Java; you'll find there's a 64MB "rt.jar" file that provides a lot of stuff. One goal of Jigsaw is to allow you to write smaller Java applications on memory-constrained devices.
Jigsaw does an OK job at modularizing Java, but has mostly failed at its other goal: to provide a standard module system that Java developers would use. I'm sure somebody's excited to use Jigsaw in their application code, but not many.
For example, Jigsaw's module system has no notion of libraries with versions. Imagine using Maven or Gradle without any version numbers. That's Jigsaw.
Jigsaw also set a bunch of other rules that get broken a lot in practice: no circular dependencies, immutable dependencies declared up front, resolve all modules eagerly, etc. These are good guidelines, but it may not be appropriate to make them iron clad rules.
In contrast, there's a hugely complicated monster module system implemented in Java userland, OSGi. OSGi has a ton of features, including letting you load multiple versions of the "same" jar at once, so one part of your app can use the old version while another part uses a newer version. (And then there's Maven, Gradle, etc.)
This certainly wouldn't be the first time Java tried to deliver a "standard" solution for a problem that we used to solve in userland that went ignored by Java's dev community. (Logging?!) If we all ignored Jigsaw and kept using Maven/Gradle/OSGi, but the Java platform became more modular, that's probably a win.
But Jigsaw includes another poisonous feature; it "improves security" by forbidding access to internal JDK APIs like sun.misc.Unsafe, which provides access to direct memory management. For better or worse, that internal API has been used and abused by a lot of popular Java infrastructure libraries, so they're now introducing a new Unsafe feature in Java 9, but it's not the same one, "breaking" compatibility. It's their reserved right to break that API, but but but.
And finally there's the fact that Java 9 has taken a hugely long time, and this is significantly due to Jigsaw. If Jigsaw misses Java 9, does it land in Java 10? Throw it out completely? (Does Java ever get modularized?)
Look at this module graph:
http://download.java.net/java/jdk9/docs/api/javafx.web-summa...
To figure out the set of JARs you need, you need to specify which JARs your program needs, and then follow the dependencies. Which is what the new jlink tool does.
And, sun.misc.Unsafe isn't actually restricted. Plenty of other internal APIs are but they did actually look at what apps were using the most frequently and not restrict them: you can still access Unsafe (or most of it at least) in java 9 apps (and any internal API by just setting some command line flags).
But this is Java, so everything is extra stupid. I can't say I have had much experience with Maven but I will say that what little bits I saw left me wanting to nuke it's creators from this planet. Even with nothing to do you can trust the Maven build to take an hour as it very slowly polls a bunch of online repositories and then does a bunch more tasks all for naught.
Then there is the OSGi system, but that is a synonym for "Eclipse" and all the cool kids want nothing to do with that, it's one wholly closed ghetto. Can't blame them, the x0.01 engineers that designed OSGi figured a mere module system is beneath them, so they integrated what seems to be a half-baked dependency injection system based on runtime-checked XML files. They figured type checking is holding them back. Also the tool support is entirely absent unless you are willing to use a null pointer exception throwing UI abomination in Eclipse.
My primary experience with Gradle has been in the context of Android and I figured people that come up with a build system where you can't go back and build software a mere 3 months old should really find a different job.
If you aren't a regular Java developer, and you pull a simple GitHub project and build it, it might need download the dependencies, source code, and docs (if the build is configured as such).
The next time you run, it will be cached and finish quickly.
No different than one of your first npm installs .
There was actually a lot of talk about JC Penny on HN when Ron Johnson took over