|No Vote For Java's Project Jigsaw Module System|
|Written by Mike James|
|Wednesday, 10 May 2017|
Java 9 stands a chance of being released without its biggest feature, modules, due to a vote by the JCP Executive committee. Interestingly the revolt was mostly led by two companies which have alternative module systems.
Project Jigsaw, concerned with making Java modular, was originally planned to be part of Java 7 but was bumped to Java 8, together with Project Coin and Project Lambda shortly after Oracle took control of Java in 2010. Then in 2012 we reported in Jigsaw Shelved Until Java 9:
Oracle is dropping Jigsaw from Java 8 in order to meet the scheduled release date of September 2013.
As we now know it took until March 2014 for Java 8 to be released and the release date for Java 9 has already been postponed twice - from September 2016 to March 2017 and currently July 2017. Now Project Jigsaw's inclusion in JDK 9 has been voted down, by 13 to 10, and this is likely to cause at least a delay until things are sorted out.
This is an interesting mess that seem to have both politics and tech mixed into it. An open letter from Mark Reinhold criticized Red Hat and IBM for not being behind the project:
Red Hat Middleware initially agreed to the goals and requirements of the JSR, but then worked consistently to undermine them. They attempted to turn this JSR into something other than it was intended to be. Rather than design one module system that is both approachable and scalable they instead wanted to design a “meta” module system via which multiple different module systems could interoperate on an intimate basis. I can only assume that they pursued this alternate goal in order to preserve and protect their home-grown, non-standard module system, which is little used outside of the JBoss/Wildfly ecosystem.
JBoss has its own module system and IBM is a heavy supporter of OSGi:
IBM has said very little during the course of this JSR. After they announced that they would vote against it they later sent a list of specific issues to the EG, but only in response to a request from another EG member. None of those issues is new, many of them were discussed long ago, and IBM was silent during most of the discussions.
IBM’s recent position appears rooted in a vague desire for “closer consensus” amongst EG members. I would prefer more consensus too, but that is not possible given Red Hat Middleware’s position. I can only conclude that IBM has decided that their interests are best served by delaying this JSR and, also, JSR 379 (Java SE 9)—which is regrettable.
Both RedHat and IBM voted against the proposal, as did Eclipse another heavy OSGi user. However, it is not so much the existence of an OSGi or JBoss cabal, more that these have been the voices that have been critical of the proposal. Depending on who you ask the criticisms are worrying or just plain off target.
It seems that what is happening is that Jigsaw is being unfavorably compared with existing module systems. For example RedHat's open letter starts with:
The Jigsaw implementation is a new module system which is has worked successfully for modularising Java itself, but is largely untried in wider production deployments of any real applications on top of the JVM. Many application deployment use cases which are widely implemented today are not possible under Jigsaw, or would require a significant re-architecture.
Neither JBoss nor OSGi has met with any widespread support in the sense that neither is a defacto module system for Java. OSGi, the more popular, has a reputation for being dense and unfathomable and so flexible that it is over complex.
Rather than being all-encompassing, the aim of Jigsaw is to usable by the average Java programmer and not just the specialist. It is also designed be used by the JDK itself, making Java modular from the inside out.
It doesn't matter how much it is denied, the smell of self interest lingers around the vote. Reinhold says in his letter:
As you consider how to cast your vote I urge you to judge the Specification on its merits and, also, to take into account the nature of the precedent that your vote will set.
A vote against this JSR due to lack of consensus in the EG is a vote against the Java Community Process itself. The Process does not mandate consensus, and for good reason. It intentionally gives Specification Leads broad decision powers, precisely to prevent EG members from obstructing progress in order to defend their own narrow interests. If you take away that authority then you doom future JSRs to the consensus of self-serving “experts.”
Unfortunately the majority has spoken and we have another example of a democratic process yielding results that many onlookers find difficult to accept.
Jigsaw was pushed out from Java 8 to Java 9 by the difficulties of implementing it, but there is probably not much point in removing it from Java 9 as without it the release looks more like a decimal point upgrade.
or email your comment to: firstname.lastname@example.org
|Last Updated ( Wednesday, 10 May 2017 )|