Project Jigsaw Late for the Train: Deferment ratified
Back in July Oracle chief architect Mark Reinhold's blog piece Project Jigsaw: Late for the Train proposed deferring Project Jigsaw from its originally scheduled release in Java 8 for at least 2 years until Java 9.
The deferment was subsequently ratified by the JSR 337 Expert Group.
InfoQ's article capturing reactions generated quite a flurry of activity from our readers.
In his responsa blog-entry Reinhold addressed most of the key questions, and discussed history, rationale, and alternatives.
In summary, Reinhold explained that the JDK modularization is complex, and Sun Microsystems could not sufficiently staff it. Adopting existing technologies such as OSGi and Maven was not an option, as these do not address all of the requirements.
One commentary went as far as to propose reappropriating Project Lambda staff to work on Jigsaw, delaying Project Lambda to Java 9, but Reinhold classified that as unfeasible.
One proposal however remained unanswered in full detail:
Project Jigsaw consists of two phases. As Reinhold describes them:
In the first phase we're exploring an approach to modularity that's markedly different from that of existing Java modularity solutions. We've assumed that we can change the Java programming language, the virtual machine, and the APIs. Doing so enables a design which can strongly enforce module boundaries in all program phases, from compilation to deployment to execution. That, in turn, leads to better usability, diagnosability, security, and performance. The ultimate goal of the first phase is produce a working prototype which can inform the work of the Module-System JSR EG.
The second phase will produce the reference implementation of the specification created by the Module-System JSR EG. The EG might ultimately choose an entirely different approach than the one we're exploring now. If and when that happens then Project Jigsaw will change course as necessary, but either way I think that the end result will be better for having been informed by our current work.
So why not deliver the ostensibly simpler first phase in Java 8 and just defer the second phase to Java 9? Reinhold responded:
If we deliver a module system in one release but don't use it to modularize the JDK until some later release then we run a big risk of getting something fundamentally wrong. If that happens then we'd have to fix it in the later release, and fixing fundamental design flaws after the fact almost always leads to a poor end result.
The Expert Group unanimously agreed. In the words of one EG member:
Since my impression is that we lack a clear strategy for making this happen in time for SE 8 without badly delaying it, I vote aye.
Providing a modularization framework is a key deliverable, and the risk of delivering that phase independently is substantially smaller than the actual JDK modularization. It would be interesting to learn whether or not our readers feel it is worth the risk to provide this key deliverable early, in Java 8, and defer the JDK modularization to Java 9?
If you have a different perspective let's hear your opinion in the comments below.
Evolving Culture and Values. Understanding the Tradeoffs. Growth through Failure. The Importance of Leadership and Open Communication.
Pedram Keyani Mar 11, 2014
Summly: An Award Winning Mobile App's Journey to the Cloud with Five-9s Availability on a Shoestring Budget
Eugene Ciurana Mar 11, 2014
Christophe Achouiantz Mar 11, 2014