Jigsaw Deferred until Java SE 9
Despite being a difficult decision to make, doing so allows more focus to be given on the module system in order to get it right, without having to delay the release of Java SE 8, scheduled for just over a year's time in August 2013.
The decision is reminiscent of the well executed plan laid in 2010 for Plan B, which deferred the addition of Lambdas (aka JSR 335) until after JDK7 was released. This allowed JDK7 to be released around a year ago (July 2011), some four and a half years after the prior JDK6 released.
To gain stability and a future roadmap, the JDK will be released every two years in what is being referred to as the biannual release train, similar to Eclipse's annual release train – though, as Reinhold notes, at the end of the Summer rather than before, and at half the tempo.
This allows large organisations to plan when to upgrade to a newer version of the JDK, and using agile planning techniques, releasing on a regular schedule with contents that are ready rather than trying to rush or delay releases.
Unfortunately this means that JDK8 will not have a module system based on Jigsaw when it is released next year. The delay in introducing modularity does not affect general developers; but as the code-base of software grows, modularity becomes a necessary tool in software architecture. Module systems such as OSGi and PojoSR already provide a runtime support for modules; modularity forms a key part in many build and runtime systems, as well as enterprise application servers.
Although adding modularity can be done after the fact, with code bases that have a long history (and typically haven't been designed with modularity in place) retro-fitting modules can be a challenging task. Few would expect that the JavaBeans API would need a dependency on a GUI; yet the
java.beans.Beans#instantiate() method contains a reference to
java.applet.AppletInitializer which directly depends on the
java.awt packages. As a result, retro-fitting modularity to the JDK remains a significant challenge; and as the number of packages increase, the accidental dependencies between them can increase. The
java.net packages all have circular references with each other which makes splitting them into different modules difficult.
Finally, the delay to the introduction of Jigsaw will give more time for Oracle and other modularity experts to refine the proposals in place and to apply the thoughts and development plans already created. As Mark identifies on his blog, the delay to Jigsaw is not through lack of work, effort or implementation achieved so far; but rather as a means to avoid delaying the planned JDK8 release and to ensure that the modularity implementation for the JDK platform is the best it can be.
I do wonder...
What about byte code?
Jigsaw was part of plan B
You say "The decision is reminiscent of the well executed plan laid in 2010 for Plan B, which deferred the addition of Lambdas (aka JSR 335) until after JDK7 was released" but Plan B deferred both Lambda and Jigsaw. Jigsaw was also in the original release of Java 7.
•Plan A: JDK 7 (as currently deﬁned) Mid 2012
•Plan B: JDK 7 (minus Lambda, Jigsaw, and part of Coin) Mid 2011
Re: I do wonder...
I wonder if the addition of lambdas will be postponed too
The last I heard, the Lambda project was still on schedule for inclusion in Java SE 8.
There were also some extraordinary reasons why Jigsaw was delayed, that hopefully will not repeat.
Wouldn't it be a good move for Oracle to focus on enhancing the byte code and runtime instead of the Java language?
Cameron Purdy | Oracle
Re: I do wonder...
why not cutting Jigsaw in half ?
Dominique De Vito
b) could be late, it’s not that much awaited.
but a) is very important, because there are out there true use cases (see OSGi and Maven)
If Oracle truly listens, it should be delivered ASAP: why not a 8.5 release ?
Is there nothing inside Jigsaw that is ready and could be included inside JDK 8 ?