JavaOne: Jigsaw and Java Modularity
I started off the morning at a pair of Java modularity talks by Mark Reinhold on Jigsaw and from Alex Buckley on JSR 294. Mark’s talk was apparently a dup of the technical general session yesterday but I missed that so that was actually good for me.
Project Jigsaw aims to provide a module system for the JDK itself (also open for external users). This system provides the means for packaging and deploying applications based on modules. I found it somewhat hard to separate in this talk which parts were Jigsaw and which parts were defined by JSR 294 but Alex’s subsequent talk helped further break that down.
Modules will enable us to more quickly download (or startup) a smaller subset of the JDK than the whole thing and provide a better way for us to package, find, download, and deploy our applications.
The more I saw of this talk, the more I realize the scope here is ambitious – there is a pretty coherent vision in this demo and it’s broader reaching than I had previously understood. The vision includes a complete overhaul of how we compile, package, and startup our Java applications. In particular:
That’s big and important, so let me say it again:
That means that when you write your application, you break it into modules (think projects in Maven or Eclipse, etc). Each module declares it’s dependencies. When you compile the code, you compile it with a modulepath. There is no classpath – the modules define the dependencies and javac can use the module metadata and modulepath to figure that out.
Mark’s demo showed using a new jpkg tool to combine a bunch of classes to build a debian package:
jpkg -m classes -d . -c hello deb org.hello
You would then get this into some debian repository (I don’t know anything about linux package mgrs sorry) and you can then retrieve that package through normal package managers (he was demoing with Synaptic).
There was also a new jmod tool to look at what modules are installed:
There were some very good questions at the end that pointed out some major holes that still need to be filled. In particular, it was noted that there is no standard packaging format or package management system on some relatively important OSes like Windows and Mac. :) Also, there is no platform-neutral deployment packaging format – the jpkg is building platform-specific packages and you would then need to build one for every platform you want to publish. That seems to throw a big wrench in between the “Write Once” and “Run Anywhere” steps that involves creating N packages.
But these are solvable problems. I see the vision now more than I ever have in the past – it’s compelling but it seems like a long way to go in a short time for Java 7.
I should note that if you don’t want to use modules, everything should be backwards compatible and you can continue doing what you do today.