We voted No because we want to see final consensus on the last few outstanding issues as well as some bedding in time of recent, far-reaching consensus decisions. No we don’t think this should or will delay Java 9 significantly, we expect a re-submission and eventual “Yes” vote to this specification within 30 days, please see the JCP Process Document for how this works. No, we don’t think JPMS/Jigsaw is fundamentally flawed. Yes we want extra time and thought going into JPMS by the wider ecosystem (and its authors) as this new module system will impact Java far more than the move to generics in Java 5.
The results of the vote on the Public Review for this JSR are here: https://jcp.org/en/jsr/results?id=5959
Our official comment
We echo SAP’s comments in that we absolutely recognize the tremendous achievements and the great work that has been carried out until now by the EG members as well as (and especially) by the Spec Lead himself.
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. However, there are still on going conversations on some of those issues and there simply has not been enough time spent by the ecosystem to discuss some of the new designs in enough depth or enough time spent implementing and testing prototypes based on the latest spec, e.g. The Eclipse ejc compiler or the latest Automatic Module Naming design in Maven.
If required, we very much look forward to being able to vote ‘YES’ in <= 30 days on a version that has had that little bit of extra time for the EG (and the ecosystem) to discuss / implement / test some of these difficult spec items. Certainly the last 14 days have shown that consensus can be reached even when viewpoints have started in opposing corners, and we think another short time period to really bed in the last sticking points is needed.
We voted “No” based on careful technical analysis of JPMS, the RI (Jigsaw), comments on the mailing list as well as out in other public forums. We then put the existing specification to the test on a Java 9 hackday along with the Virtual JUG and ~15 JUGs worldwide. The conclusion was that JPMS still has some outstanding issues to be resolved or issues that (despite having recent resolutions), were still not bedded in the minds and/or prototypes of the larger ecosystem.
For our membership, interoperability with the Maven build ecosystem and the ability to build an alternative compiler implementation (i.e. Eclipse’s ejc compiler) is paramount. Although consensus is rapidly forming around those two items, our membership felt that they needed some extra time before they felt comfortable with voting “Yes”.
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.