Project Jigsaw delay defended by Chief Architect Mark Reinhold
Mark Reinholds forthright explanation of Project Jigsaws delay has failed to quell dissent – but we agree that its probably the right call.
proposed deferral of the long-awaited modularisation of the
Java platform in Project Jigsaw caused quite the stir last month.
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
java.net 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
The ensuing month has seen a lot of crossfire from Java developers
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
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
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
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
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
Tweet from Java Champion
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
What did you make of Reinhold’s response, and of Project Jigsaw
– Comment below?