The aim of Project Jigsaw is to design and implement a standard module system for the Java SE Platform, and to apply that system to the Platform itself and to the JDK.
Jigsaw is currently slated for Java 8. The proposed development schedule for Java 8 expects work on major features to be finished by May 2013, in preparation for a final release around September. Steady progress is being made, but some significant technical challenges remain. There is, more importantly, not enough time left for the broad evaluation, review, and feedback which such a profound change to the Platform demands.
I therefore propose to defer Project Jigsaw to the next release, Java 9. In order to increase the predictability of all future Java SE releases, I further propose to aim explicitly for a regular two-year release cycle going forward.
Goals A standard module system for the Java Platform will ease the construction, maintenance, and distribution of large applications, at last allowing developers to escape the “JAR hell” of the brittle and error-prone class-path mechanism. A truly modular Java Platform will support customizable configurations which scale from large servers down to small embedded devices and, in the long term, enable the convergence of Java SE with the higher-end Java ME Platforms. Modular applications built on top of a modular platform can be downloaded more quickly, and the run-time performance of the code they contain can be optimized more effectively.
Progress Initial work toward these goals has been underway in Project Jigsaw in the OpenJDK Community for some time. Guided by a draft requirements document written in collaboration with key stakeholders we’ve thus far produced an initial design for a module system, used that to modularize the JDK, and published an open-source prototype implementation which anyone can download and evaluate.
Despite this progress, some significant technical challenges lay ahead. Modularizing the Java SE Platform and the JDK while maintaining compatibility for existing code is an incredibly delicate task which requires careful changes throughout both the specification and the implementation. We have, moreover, yet to design and prototype an approach to supporting containers such as IDEs, Java EE application servers, and applet containers, all of which require some amount of reflective dynamism. We’re reasonably confident that we can work through these issues, but doing so will most likely take us past May 2013.
Bake time Above and beyond any specific technical problems, the introduction of a truly modular Java Platform is a momentous transition which will, eventually, affect the entire Java ecosystem. It will change the way that the Java Platform itself is deployed, and it will change the way that developers build and deploy libraries, frameworks, tools, and applications.
We must therefore allow adequate time for broad review, testing, and feedback from all segments of the community on both the design and the implementation via Project Jigsaw, via the Java SE 8 Platform JSR (337), and, primarily, via a forthcoming JSR to define a standard Java Platform Module System. We should not try to rush to complete, in less than ten months, such a deep change with such wide impact.
At this point, then, the options available are achingly familiar: Either delay Java 8 until Jigsaw is complete, most likely slipping its final release to mid-2014, or else ship Java 8 on time, around September 2013, and defer Jigsaw to Java 9.
Schedule vs. features To put the stark choice before us in another way, and more generally: When a train is scheduled to leave the station should we hold it until all the expected passengers are on board? Or should we raise the ball, let the train go, and tell anyone who’s late to wait for the next one, which will also depart precisely as scheduled?
In all the years I’ve worked on Java I’ve heard repeatedly that developers, partners, and customers strongly prefer a regular and predictable release cycle. Developers want rapid innovation while enterprises want stability, and a cadence of about two years seems to strike the right balance. It’s therefore saner for all involved — those working on new features, and those who want to use the new features — to structure the development process as a continuous pipeline of innovation that’s only loosely coupled to the actual release process, which itself has a constant rhythm. If a major feature misses its intended release train then that’s unfortunate but it’s not the end of the world: It will be on the next train, which will also leave at a predictable time.
Keep the beat In this light I think the best choice is to defer Project Jigsaw to Java 9, and to aim for a two-year release cycle going forward.
On this plan Java 8 will ship on time, around September 2013. Assuming all else goes well it will include the widely-anticipated Project Lambda (JSR 335), the new Date/Time API (JSR 310), Type Annotations (JSR 308), and a selection of the smaller features already in progress. Java 9 will follow two years later, around September 2015, with Jigsaw and, no doubt, various other features yet to be determined. Work on Jigsaw will, in the meantime, proceed at full speed.
Deferring Project Jigsaw to 2015 is by no means a pleasant decision. It does, however, appear to be the best available option. I have therefore today asked the Java SE 8 (JSR 337) Expert Group to consider it.