Java 7 has three principal targets. The first is to modularise the Java platform through project Jigsaw. The second is to evolve the JVM into a multi-lingual platform through invokeDynamic and the Da Vinci Machine project, and the third is to address some common productivity problems that Java programmers face through Project Coin.
Modularisation of the Java platform offers a number of significant advantages. It improves performance by removing interdependencies that have grown up between classes in the JDK, it reduces download size by allowing subsets of the JDK to be downloaded instead of the entire platform at once, and it allows a subset of the JRE to be installed on memory constrained devices such as embedded controllers.
Sun is taking a two-pronged approach to building modularity for JDK7 – JSR 294 and Jigsaw. JSR 294's primary purpose is to improve the fidelity between the compile time and runtime environments. It will add language features to support module systems in Java, and update key components that currently reference the class path such as the javac and the JVM itself. Ultimately it will remove the need for the class path altogether. Since it is separate from Jigsaw it can be used by other module systems such as OSGi, and even by other tools which handle dependencies such as Google's Guice or a future version of JSR 299 (Java Contexts and Dependency Injection).
Jigsaw will build the module system for Sun's implementation of JDK7 using the features developed as part of JSR 294. It is an implementation detail of Sun's JVM and, as such, will not be standardised through a JSR, and isn't technically part of Java SE. Perhaps surprisingly it has this in common with the class path that it aims to replace which, whilst the de facto standard for Java host systems, isn't actually part of the Java language specification either. To develop Jigsaw, Sun has created an open source sub-project of OpenJDK, also called Jigsaw, which will hold both the reference implementation of JSR 294 and the design and implementation of the Jigsaw module system.
Alex Buckley's presentation at this year's JavaOne provides some technical details on how JSR 294 and Jigsaw work. The key feature is the introduction of a standard module-info interface that Java programs can use to specify dependencies and other details. Details include the module id, the application's main class, modules which the program provides and modules on which it depends. They may optionally include version information, which should make it easier for Sun and others to make modifications to widely used libraries and APIs in the future. An example from Buckley's slides:
module org.planetjdk.aggregator @ 1.0 {
system jigsaw;
requires module jdom @ 1.*;
requires module tagsoup @ 1.2.*;
requires module rome @ =1.0;
requires module rome-fetcher @ =1.0;
requires module joda-time @ [1.6,2.0);
requires module java-xml @ 7.*;
requires module java-base @ 7.*;
class org.planetjdk.aggregator.Main;
}
Using this module information, Jigsaw's packaging tool (jpkg) is able to create a mapping of deployment artifacts which can vary according to the platform and be more tightly bound to its capabilities. As such Jigsaw will make Java desktop applications appear more as first class citizens on the various platforms that Sun supports, a critical step in Sun's efforts to revitalise desktop Java. Mark Reinhold demonstrated some of the current capabilities at JavaOne, using the Synaptic Package Manager for Linux to gradually build up the requirements for a simple application, starting from a base Java module and adding additional modules such as AWT and Swing.
Sun's decision to build Jigsaw rather than use an existing module system such as OSGi has been hugely controversial and Sun has done a poor job of articulating the reasons why it has decided to go this way. In a recent Java Posse podcast however, Mark Reinhold and Alex Buckley did provide some technical details as to the differences between the two approaches which shed some light on why Sun decided to build its own system. Aside from binding the packaged application more to the platform on which it is to run than does OSGi, the dependency models in the two systems are different. Sun needed to be able to split packages into different modules and have them loaded into the same classloader at runtime - so for example a package like java.util might be split into different modules (or even different implementations for memory constrained devices). To support this Jigsaw has a concept of a local dependency which is recursive. So if module 'Swing' has a local dependency on module 'AWT' and module 'AWT' has a local dependency on module 'base', then at runtime modules Swing, AWT and base will all end up in the same classloader. Although OSGi has a similar concept in the form of fragments, these are much less flexible in that they cannot themselves express dependencies.
Eric Newcomer, Enterprise Expert Group co-chair, remains unconvinced. In a recent blog post he described Jigsaw as "Sun's latest attempt to re-invent OSGi, or in any case block OSGi or create a substitute they can control" going on to write:
"I was not at JavaOne this year, so I may have the wrong impression sitting remotely as I am, but my understanding is that the Project Jigsaw talks and demos did not mention OSGi. Nor did the descriptions of the plans for Java 7. So the short answer to the question of whether Project Jigsaw is a threat to Java modularity is that yes, it is."
Other bloggers though have responded more positively with many being impressed by Sun's efforts. Amongst them Bram Bruneel was impressed by the native package generation:
"..Mark showed us a nice demo of the packaging and distribution of Java apps on Ubuntu. [The] JDK modules will be normal Debian packages and you will be able to create your own Java application, export it to a Debian package and define a dependency towards the Java modules you need to run your app."
Alex Miller, in his write up of the talk, makes the point that Jigsaw is pretty significant:
"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."
Glyn Normington has listened to the Java Posse podcast and commented:
"It's nice to see some technical details emerging and I can start to see why OpenJDK would prefer a different design for modularity to that of Apache Harmony."
And Dalibor Topic is particularly excited by the possibilities of the native packaging tool:
"The separation of concerns between the language concept of modules and the concrete module system allows using tools like jpkg to create an N:M mapping of abstract modules to concrete deployment artifacts. The freedom to pick the best delivery mechanism for a given platform is an obvious benefit, for example - on platforms with a package manager the most user-friendly way to deliver the JDK is via corresponding packages. Going native through ahead-of-time compilation, where platforms demand it, becomes possible, too, without breaking out in sweat - it turns into just another post-processing step that could be applied to modules before they are wrapped into deployment artifacts, like pack200 and LZMA compression was in the current jpkg code. Splitting a module transparently into a couple of native deployment artifacts becomes easily feasible, as well - JNI libraries, for example, can be turned into separate, architecture-specific packages, reducing the download size for complex applications with native code for several architectures (incidentally that's just like the JDK), as well as making it a bit easier to deliver just a tiny updated package for the native library portion in case of a good old buffer overflow in the native code."