Picking up the pieces

Project Jigsaw delay defended by Chief Architect Mark Reinhold

Chris Mayer

Mark Reinhold’s forthright explanation of Project Jigsaw’s delay has failed to quell dissent – but we agree that it’s probably the right call.

The proposed deferral of the long-awaited modularisation of the Java platform in Project Jigsaw caused quite the stir last month. The decision by Mark Reinhold, Chief Architect of the Java Platform Group at Oracle, was supported and criticised in equal measure. Some agreed that Jigsaw needed to be perfect to make Java SE 8, whilst others bemoaned the delay, having long missed its original release date in Java 7.

From the array of public polls that were taken (such as the one), opinion was mixed but one thing was apparent – a collective sense of disappointment that the much-needed modularity would not be ready until at least JDK 9 in 2015.

The ensuing month has seen a lot of crossfire from Java developers and respected figures in the industry, nearly all of which were questions revolving around why an alternative option hadn’t been considered. Many, for example, wondered why OSGi wasn’t an option. We were all left in the dark here. Until now.

At the end of last week, Mark Reinhold took the time to respond to criticism in a measured response entitled Project Jigsaw: Late for the train: The Q&A.

It’s probably a good thing that Reinhold took this long to reply. He had clearly taken on board feedback from all quarters and covered nearly every question that had been posted while shedding light on various decisions made behind the proposal.

It’s important to note at this point that this decision hasn’t been ratified by the Expert Group, but that seems all but a formality when it’s proposed by the Chief Architect. Project Jigsaw itself comes in two main phases – the first of which explores the approaches to enabling modularity within Java, whilst the second is the formal reference implementation stage, where the Expert Group might discount the recommended option from Stage 1 entirely. Unlikely, but possible.

Reinhold again reiterated the reasons for the delay, citing the transition of power between Sun Microsystems to Oracle and early staffing issues as two key reasons. The main driver though is the sheer technical difficulty of modularizing the JDK, which we at JAXenter respect.

Reinhold went on further to detail other reasons why modularization has proven so difficult. He assured those who have assumed little progress had been made, that this was simply not true, adding that ‘much of the core functionality’ had been prototyped, working at compile and run times.

The most interesting section of the post is the Maven & OSGi answers Reinhold provides. He says that Maven wouldn’t be an option to support modularisation at run time, whilst OSGi didn’t have “wide enough interest” to be considered.

The responses here are certain to create further debate, especially from prominent members of those communities. Some, already in the comment section have debunked his explanations, including OSGi enthusiast David Bosschaert who believes OSGi has more worth than Reinhold suggests His own blogpost after the initial argument makes very good points.

Oracle clearly hold interest in seeing OSGi/Jigsaw interoperability happen. After all, it would be foolish to discount it and its community entirely. The formation of Project Penrose shows their intentions towards OSGi, but not as Java’s standard for modularity. Some might feel aggrieved by the decision, as the tweet below suggests, but the OSGi will still be strong, especially so with Jigsaw pushed back until 2015.

Tweet from OSGi expert Neil Bartlett re Reinhold’s post

We applaud Reinhold for taking time out to post this incredibly well-thought out response that was needed for Java developers to know where the land lay. However, it does bring about some further questions, such as these from Google’s Alexis Moussine-Pouchkine.

In our opinion, clarity on the Java EE lifecycle is the one that needs to be addressed first. It leaves arguably the biggest customers in limbo, unsure of the scheduling their version. In addition, we’re unsure where this leaves vendors creating Java Platform-as-a-Service options. Modularity is certainly a big deal to them – could they jump ship?

It again comes down to the age old debate of innovation vs stability, and in turn, weighing up the desires of the wider Java community against those of the enterprise. If you’re invested in Java, you obviously want to see the language grow, but this idea of ‘growth’ is interpreted in different ways. Arguably, for the enterprise, the current cycle of two year releases is often too short a turnaround time for them to consider getting the latest version. Some want shorter cycles, some want longer. You can’t please them all.

Whichever way this decision went, it was bound to upset someone. Despite this fairly transparent and honest response, under the current format, many consider Java 8 to be one to miss. Even with features such as closures in Project Lambda (JSR 335) and ironically the new Date/Time API (JSR 310), for some, Java 8 isn’t necessarily the release that it could have been. We now know the full features list and milestone dates for JDK 8 Plan B and Project Jigsaw won’t be appearing any time soon.

Tweet from Java Champion Peter Pilgrim

On the evidence provided so far, we have to agree that the right decision was made. Jettisoning excess Java baggage takes time and moving away from such a monolithic system is certainly no easy task. It is by no means a quick fix – we understand how pivotal this project is to (dare we say) Java’s survival. But there’s an inherent danger that yet another delay could spell deep trouble will people sit up and take notice, or will they have already moved on?

What did you make of Reinhold’s response, and of Project Jigsaw – Comment below?

Inline Feedbacks
View all comments