It’s a No for JSR 376: The EC has not approved the Public Review Ballot
© Shutterstock / dslaven
The Public Review Ballot for JSR 376, the Java Platform Module System is behind us. The EC has not approved it and now the race to build a better version has begun. Let’s dissect the vote log and representatives’ comments after casting their votes.
All 23 representatives of organizations and individual members voted in the Public Review Ballot on the acceptance of JSR 376. There were 13 votes against and 10 in favor — as a result, the EC did not approve the ballot.
Final results of the Public Review Ballot for JSR #376:
According to the vote log, IBM voted No with the following comment:
IBM’s vote reflects our position that the JSR is not ready at this time to move beyond the Public Review stage and proceed to Proposed Final Draft. The JSR 376 Expert Group and the public have raised a number of reasonable issues and concerns with the current public review draft of the specification that warrant further discussion and resolution. We advocate work continuing amongst all members of the Expert Group to address the issues documented on the mailing lists. IBM would like to see closer consensus amongst the entire Expert Group before this specification proceeds to the next step.
Keil Werner acknowledged the concerns that IBM and others have and claimed that “most of their concerns are still unanswered by the EG or Spec Leads, which at this point it does not make this JSR seem ready yet.”
Hazelcast, which recently told JAXenter that they would not support the draft, also voted No with the following comment:
From our point of view, the lack of consensus inside the EG is a dangerous sign, that either not all issues are clarified the way they have to or that certain issues were marked solved from a single point of view. Overall, we acknowledge, that the state made big progress over the last months and a lot of issues were addressed with the community but it seems that the state for a public review ballot is not yet right.
In addition, problems with popular build tools don’t seem like a good starter. Our understanding of the EC is, that part of the work is to prevent the Java ecosystem from harm and in the current state the JSR376 cannot be seen as ready for that matter.
The Red Hat middleware team has publicly mentioned their concerns before the voting began but added that a No vote is “the correct course of action.”
In previous votes and comments on the EG list, we have articulated the view that from a middleware/SE developer perspective we believe that Jigsaw does not fulfill its original goals of being a module system which can be used by the likes of Java EE. We understand that after inception the original goals of the EG were initially changed to try to focus it on a module system to be used solely to modularise the JVM and that caused some architecture and implementation approaches which made it difficult for it to be a module system to be used by SE and EE developers. Unfortunately, during the lifetime of the EG, the goal appeared to switch back to trying to make it a module system for Java developers but previous implementation decisions appear not to have been revisited or could not be changed and as a result, the expectations around Jigsaw have not been met by the implementation. Therefore, we are worried about the impact of the current implementation on the wider Java community, particularly existing projects and products including, but also beyond, Java EE. We have raised several issues within the EG list to try to rectify a few of these things in what we believe would have been a minimally invasive manner but they have been rejected. Furthermore, we believe that there has been insufficient consensus in the EG for a series of changes so dramatic to the JVM and which could have an equally dramatic impact on the Java communities, as well as a lack of openness on receiving and discussing community input. We believe that a more considered evaluation of all input and consensus gathering should not take too much time and would result in something which would be better received by the entire Java ecosystem.
Although Software AG voted No, they were rather positive about the next 30 days, which can be used “to attempt to form a healthier consensus within the EG.” They also added that specific attention should be paid “to the migration path for existing software in a modular world and on the co-existence of the specification with existing established Java practices and build systems (#ModuleNameInManifest, #CyclicDependences, #AutomaticModuleNames, #AvoidConcealedPackageConflicts, #MultiModuleJARs).”
SAP SE acknowledged the “tremendous achievements and the great work that has been carried out until now” but chose to vote No. They argued that “while the JPMS is in pretty good shape for the modularisation of the Java platform itself, there are still some rough edges for libraries and frameworks outside the Java platform which should be addressed and agreed upon before the final approval of the specification.
During the development and up to now it has not always been clear what in the development of the JPMS/Jigsaw is considered an implementation detail and what will be part of the standard specification. Features like the binary format of modules and runtime images, the jlink tool and new class attributes like hashes and versions are examples for non-standardised implementation details.
What we 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.
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!”
London Java Community echoed SAP’s comments and, even though they admitted that “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, there are still ongoing 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.”
Twitter, Inc. voted No because they are concerned that “this JSR will prove disruptive to Java developers, while ultimately not providing the benefits that would be expected of such a system.” They expressed concern over the fact 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 (in particular, collisions in non-exported package names are arguably incompatible with the “non-interference” and “strong encapsulation” goals) it can address real pain points that Java developers have today (e.g., dealing with multiple copies of the same package by hiding them as non-exported packages). This would encourage more developers to rapidly adopt modular development. Finally, we think broader consensus among the JSR lead and the EG members is necessary for such an important JSR.”
Tomitribe believes that voting No will indirectly help this JSR: “While the 30 days window afforded by a No vote will not gain a perfect consensus, we do believe it will help significantly. It allows time for the dust to settle; with all the changes in the last 2 weeks, what exactly will be presented for a final vote is in some ways less clear.”
We see positives in opting for a 30 fixed window for feedback to and from the EC as it keeps pressure which is critical for momentum. JSR-299 (CDI 1.0) went 9 months between its Public Review Ballot and Final Approval Ballot, delaying Java EE 5 significantly. We would not want to see the same happen here. The 30-day window applies both to the spec lead and essentially to the EG who knows we’ll be voting immediately after.
Though a No vote feels like rejection we ultimately believe it is the most supportive vote for gaining a greater level of consensus we believe is necessary from a JSR, while still keeping time pressure.
For more details about the votes and comments, check out the vote log.