Almost two months after the Java Platform Module System (JPMS), also known as Project Jigsaw and JSR 376, failed to pass the original public review ballot, the Java Community Process executive committee (EC) has now overwhelmingly passed the reconsideration ballot. As previously reported by InfoQ, there were a number of factors that led to EC members IBM and Red Hat, publicly stating they would vote “no”, well ahead of the original ballot deadline, and reasons that Twitter and the London Java Community ultimately voted against it.
In the reconsideration ballot, all of the EC members voted “yes” with the exception of Red Hat, who abstained from voting. In their voting comments, Red Hat explained:
Red Hat is voting Abstain at this time because although we think there has been positive progress within the EG to reach consensus since the last vote, we believe that there are a number of items within the current proposal which will impact wider community adoption that could have been addressed within the 30 day extension period for this release. However, we do not want to delay the Java 9 release and are happy with the more aggressive schedule proposed by the Specification Lead and EG for subsequent versions of Java because getting real world feedback on the modularity system will be key to understanding whether and where further changes need to occur. We hope that the Project Lead and EG will continue to be as open to input from the wider Java community as they have been in the last 30 days and look forward to the evolution of Java being driven by data from users and communities beyond OpenJDK.
Twitter, having voted “no” on the original ballot, changed their vote on the reconsideration ballot. Tony Printezis, JVM/GC engineer at Twitter, explained in his blog:
The JSR 376 Expert Group (EG) has been hard at work to clarify several ambiguities (#RestrictedKeywords, #CompilationWithConcealedPackages, and #ResolutionAtCompileTime) and make a few important changes (#ModuleNameInManifest and Relax Strong Encapsulation) in the revised JSR 376 specification.
As a result of this work, we have decided to vote Yes on the JSR 376 Public Review Reconsideration Ballot.
Relaxing strong encapsulation by default should help adoption of JDK 9, at least in the short-term, by removing an important barrier. There is now greater consensus among the EG that, with these changes, the JPMS is ready for release in JDK 9.
The London Java Community also voted “no” on the original ballot and changed their vote on the reconsideration ballot. Martijn Verburg, co-founder of the London Java Community and CEO of jClarity, and Tim Ellison, senior technical staff member at IBM, spoke to InfoQ about this latest vote:
InfoQ: What is your reaction to Red Hat choosing to abstain from voting?
Martijn Verburg: I'd like to make it clear that this is my opinion/guess. I think Red Hat voted this way because they felt that a "yes" vote would indicate to their customers that Jigsaw (in it's current form) is ready to go day one for all of their customers for all of their use cases. Red Hat have made it clear that although Jigsaw in its current form is an acceptable foundation, it is not ready for all customers and use cases.
Several items for Jigsaw that Red Hat were looking to get resolved have been deferred to a later date. Whether the resolution of those items comes in a Java 9 update release or Java 10 we're not sure of yet.
InfoQ: What has changed since the vote on May 8?
Verburg: A lot! The specific technical details are covered in the minutes:
- May 18, 2017 Expert Group Minutes
- May 22, 2017 Expert Group Minutes
- May 23, 2017 Expert Group Minutes
Some highlights include:
- Agreement on version name format(s)
- Agreement on rules around Automatic Module Naming and a guide on how to best use those (important for the Maven ecosystem)
- Dealing with multiple versions of the same module was deferred to be resolved later
- Agreement on relaxing Strong encapsulation as a default (means less apps will break out of the box, but get a warning instead)
- Tidying up on some keyword usage (allows the Eclipse compiler to work)
InfoQ: Were there any other changes/contributing factors made to JSR-376 for the vote to pass?
Verburg: *Very* crucially was that the Spec Lead and the EG actually met over conference calls and made a significant effort to improve their communication and collaboration.
Ellison: There have been a number of technical changes since the vote that closed on 8th May [1]. Some of these are relatively minor API enhancements that would have been possible even if the specification had moved to Proposed Final Draft status at that point. Others are new capabilities that support easier migration of existing code and broader adoption of Java 9 concepts in established libraries and applications. As an expert group, we got together (virtually) and discussed the outstanding issues, deciding which ones were a "must fix" in the initial release, which issues could be deferred to later Java SE releases, and which should be abandoned at this stage.
There has been some discussion within the JCP about ensuring the vitality and pace of technological enhancements to Java SE by increasing the cadence of platform releases. That has to be achieved within the standardization process that has served Java well for many years, and a forum where commercial interests can collaborate productively.
Bringing these two threads together, I hope that some of the JPMS items that were deferred may be reconsidered by a JSR maintenance release expert group quite quickly. Furthermore, by committing to an initial release any future enhancements will benefit from some real-world experience.
I wrote a bit more on this subject in a blog entry here [2], and the list of outstanding issues is documented here [3].
[1]https://www.jcp.org/en/jsr/results?id=5959
[2]https://developer.ibm.com/javasdk/2017/05/26/building-consensus-jsr-376-java-platform-module-system/
InfoQ: Are there any further changes to JSR-376 that you would like to see made to JSR-376?
Verburg: I'd like to see more work done in and around versioning and version support. At the moment the onus is still on the build tools to sort this out, but we'd like to see strong guidance from Jigsaw on this.
Ellison: Modularity is not a one-shot design. I think it will evolve as people use it and raise issues that we had not foreseen, for use cases we may not have predicted, and adapting to changes in the industry (cloud, microservices, serverless, etc). My focus has always been on working with the community and in the interests of our customers to ensure that current code is not left behind as Java SE evolves, and that new frameworks and programming models are well supported.
