Mark Reinhold (Chief Architect of the Java Platform Group at Oracle) just published a „document“ titled „Project Jigsaw: The Big Picture — DRAFT 1„, his words:
This document is an overview of the current state of Project Jigsaw, an exploratory effort to design and implement a module system for the Java SE Platform and to apply that system to the Platform itself and to the JDK.
To put it into context: this is draft 1 of the big picture, that comes after draft 12 of a jigsaw module-system requirements document. Why two documents? Is draft 12, although more complete, deprecated now?
One of goals of jigsaw – among many others, to many other IMHO – is to provide a scheme of some sort for versioning. Is this the way to go concerning versions? When it comes to documents and versions, one is not leading by example, not, not really… I am following the jigsaw from a public point of view for a while now – but I can’t tell you where to find versions 1 to 11 of the requirement document, and I find it somehow frightening to see a draft 1 on a related topic coming along. The „still to come“ topics at the end of the document can be found at draft 12 of the requirements documents.
To be honest, I have a bad feeling on all this modularization effort targeting jdk8. If I take a look at lambda (nice post here), we have a state document, a JSR and a plan to integrate it into the JDK source. Sure, we have voices complaining that it is too much, too little, to late – but hey – there is something to build upon. It is in a state we can actually believe it is coming. This feels far more solid that anything – everything – regarding jigsaw and modularization. We do not even have a JSR for modularization, as stated in the jdk 8 JSR!
Now back to the big picture document. It does not report the jigsaw status, and it is by far not as complete as the requirements document draft 12. But it does explain the syntax of module definitions on a more precise way, and does recap some of the big picture goals of jigsaw.
Big picture, the design principles:
(1) Modularity is a language construct
(2) Module boundaries should be strongly enforced
(3) Static, single-version module resolution is usually sufficient
Sounds good, but (1) is the whole point of adding modularization to the jdk, or we could just stick to OSGi. A modularization that is not enforced is not (read enforcement here), so we all agree on (2). That we are going to need split packages loaded in a common class loader because of the mess in the jdk (see java.util package) goes against (2). From the requirements document, draft 12:
In support of platform modularization, it must be possible to declare that the types defined in a specific set of modules must be loaded by the same class loader.
But (3) is something that I really do not get. Again, from the requirements document:
Multi-version support should only be enabled when type collisions can be detected and reported as errors. This most likely means that it cannot be enabled for run-time linking since detecting collisions is nontrivial.
Seriously – just one version at runtime? The whole point of versioning and modularization is that we HAVE version collisions, and we are witnessing repackaging of all sorts circumventing our version conflicts. This is why we started using something like OSGi, despite of all the doing, tooling and architectural pain.
If we can have only one version resolved, we aren’t getting any better than with ivy or maven dependency management and dependency mediation. By the way, the new Big picture is messing around with the terminology we are used to: from maven, spring – and somehow from common sense – we know „scopes“ as where to use the artifacts/ components (runtime, compile-time, test-time, etc.). Then we have different life cycles: maven defines a concise project lifecicle. Every single component model defines its own component life cycle, and regarding modules (at the same level of granularity) we have a bundle life cycle defined by OSGi. In this context, take a look at „Phases“ in the big picture…
Big picture, the phases:
Compile time
Install time
Run time
There is not much to comment here. I just have the strong feeling that this is not enough, too late, to little? The big picture turns out to be a very small one. If you really need modularization today, take a look at the really big pictures drawn by maven, spring, osgi. Even GWT – nothing more than a web framework – does provide its own little module system.
On his blog „there’s not a moment to loose“, Mark described how cool it would be to have a small memory footprint, modularized jdk. That was 2008. Lots of things changed since than.
49.008085
8.403756
