Today, the results of the JCP Executive Committee vote on JSR-376 (Java Platform Module System, commonly known as Jigsaw), were published on the Java Community Process page. There were 10 votes for the proposal and 13 votes against the public review.
This follows a week of intense public debate and scrutiny, covered previously by InfoQ and more recently by Reinhold’s plea to the JCP EC. In it, he said:
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.
It seems the Executive Committee did take this to heart, and responded in the comments indicating that the proposal was not ready in its current form. Part of the concerns were regarding the Automatic Module Name, which was to be derived from the file name if not specified in a module-info.class in the JAR file. Since file names are not guaranteed, and that any switch from a file name to an explicitly declared name could not be achieved in a forwards compatible way, the issue would have caused a significant amount of harm in the Java community. Stephen Colebourne, author of Joda Time and the Java 8 time package, wrote earlier today:
Automatic modules allow modules to depend on non-modules. But this is achieved by specifying a required clause on the filename, not the module name. This will cause pain later if modules are published depending on the filename. A new MANIFEST.MF entry allows any open source project to choose a module name and publish that choice immediately. When JPMS sees the MANIFEST.MF entry, it will use the value as the name for the automatic module.
Community members must at all costs avoid publishing modular jar files that depend on filenames. But community members can publish jar files containing the new MANIFEST.MF entry from now on (although technically the MANIFEST.MF entry is not yet finalised, it probably will be soon).
The feedback regarding automatic module names had already been reported on the expert group mailing list, and the public review draft was published with the hope that it would be rubber stamped as-is. However, over recent days Reinhold acknowledged the problems with the automatic module names, leading to a revised proposal on the mailing list. However, this was not included in the public review draft submitted to the JCP EC, with members observing in the comments that they could not vote for the proposal as it was written, since it didn’t include the final proposals discussed on the mailing list:
The LJC is voting "No" on the spec as it was submitted at the start of the voting period. During the 14 day voting period, great progress was made by the Spec Lead and the EG to reach consensus on some very difficult issues such as #AutomaticModuleNames.
What we [SAP SE] are especially concerned about however, is the lack of direct communication within the expert group. Assuming this JSR won't be approved with the required two-thirds majority, we would expect the expert group and spec lead to use the additional 30 days for regular meetings in order to sort out the remaining issues and come up with a new, more sustainable and forward looking proposal. While we're aware that it won't be possible to remedy all concerns, we think that the last days have clearly demonstrated that good compromises are still possible (e.g. the "automatic modules issue") and we're confident that the additional time could be used to submit a better specification for the reconsideration vote.
The feedback was generally positive and acknowledged the significant work done in implementing the JPMS as it currently stands. With a less than 2/3 majority of the votes, the public review period is now extended by another 30 days in order to submit an updated proposal. A subsequent vote can then be carried out based on the revised input from the discussions on the mailing list, such as revisiting the automatic module naming scheme. However, it also advised that discussions should take place on the mailing lists and not on blog posts:
Finally, we adjure all members and the spec lead to come back to the table and communicate directly to each other instead of blaming each other through blogs and open letters!
Although some may see the "no" votes as a vote against JPMS, the reality is that the JSR as it currently stands is still a work in progress, and has some rough edges that need to be ironed out before it is put to the final vote. The public review is repeatable within a 30 day window, and should the public identify further issues then they can be reviewed. However, once the JSR passes the public review, it enters a final review ballot which is non-repeatable and which is final. Although it won’t affect the implementation in the OpenJDK (where code has already landed), it will affect what other Java providers need to do in order to stay Java compliant. The alternative for Oracle is to overrule or disband the JCP as a means to rush through an unfinished specification. As Martijn Verburg posted on the London java Community blog, explaining why the LJC voted "no":
This is what the JCP is for (no, not just politics)
Casual observers and some parts of the tech media will likely come to the conclusion that this is all just about big company politics. Recent public blog posts and open letters will have fuelled that sentiment, but we urge people to read the comments accompanying "No" votes.
Although Oracle are the stewards of Java, the JCP Executive Committee (EC) is meant to act as guide for the Java ecosystem as a whole and we feel strongly that it is working as intended in this case.
Ben Evans, the other rep from the LJC to the EC told InfoQ:
The LJC has been a supporter of Jigsaw since its inception. We are keenly aware of the complexities involved in this fundamental change to the way Java applications are packaged and deployed. However, that makes it even more critical that we get the modules system right the first time.
In the last few weeks, especially since the JPMS JSR was submitted for review, the Expert Group has made great progress towards resolving outstanding issues. However, major issues remain and need to be fixed before General Availability. Most important is the proposed fix for Automatic Modules, as our community has indicated that they are primarily interested in the migration path to modules (especially for e.g. Maven-based applications).
By taking a further breathing space, it will be possible to run some hackdays and see how the community reacts to the new feature proposal, once the EG have provided some guidance for how it should be applied to existing code.
JPMS still has great potential - but more work is needed before it can be considered ready for general use.
IBM’s Tim Ellison has published a blog post following up on their comments on the vote and expressing a desire that the outstanding issues be resolved:
We remain optimistic that that the Expert Group and Specification Lead will continue to work together closely and productively on refining the draft specification. We are confident that the JSR 376 specification can be amended to improve the position on a few remaining technical issues and be presented for Proposed Final Draft without significant disruption to the Java 9 project schedule.
Twitter has also issued a statement giving their reasons for saying no, and expressing the hope that the spec lead and EG can work to resolve the outstanding issues:
Our main concern with the JPMS is that it is likely to prove disruptive to Java developers, while not providing the immediate benefits that would be expected of such a system. We are worried that this will delay wide-scale adoption of this important technology. We hope that if the JPMS accomplishes some of its original goals more comprehensively, it can address real pain points that Java developers have today. In particular: collisions in non-exported package names are arguably incompatible with the "non-interference" and "strong encapsulation" goals of this JSR. But if modules were more thoroughly isolated, it would be sufficient to allow build systems to support multiple copies of the same package by hiding them in modules as non-exported packages. Such tangible and immediate benefits could offset all the hard work developers will have to do to modularize their source code and would encourage more rapid adoption of JPMS.
For the above reason, Twitter voted "No" on JSR 376. We hope that the Spec Lead and the EG will work together over the next few weeks to address our concern, as well as all the other issues brought up by the rest of the JCP Executive Committee members who also voted "No". We are looking forward to being in a position to vote "Yes" in the JSR 376 reconsideration ballot.
Oracle remains optimistic that Jigsaw will make it into Java 9. Georges Saab, VP software development, Java Platform Group at Oracle, and Chairperson of OpenJDK governing board, told us
The JSR 376 EG have continued to make good progress on issues within the scope of the JSR. We anticipate they will continue with this until they feel it is ready for submission for reconsideration, within the 30 day window called out by the Java Community Process.