Mark Reinhold, chief architect of the Java Platform Group at Oracle, has published an open letter to the JCP Executive Committee. In the letter he expresses surprise that IBM have decided to vote against the JSR, and argues that Red Hat’s decision to vote no is motivated by a desire to "preserve and protect their home-grown, non-standard module system, which is little used outside of the JBoss/Wildfly ecosystem". He goes on to plead
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".
Many failed technologies have been designed in exactly that way.
That is not the future that I want for Java.
Responding to the furore, Red Hat’s David Lloyd has provided a summary of what he believes are the outstanding issues. In brief:
- Allow cycles to exist among modules at run time.
- Re-evaluate (piecewise if necessary) the (still very small) module primitives patch.
- Provide package namespace isolation among module path modules.
Lloyd adds
We also have a concern that the changes to reflection may still be too drastic for the community to cope with, and it's possible that this might still be a deal-breaker for other EC and EG members. I think that it is a good idea to ensure that there is consensus among the rest of the EG before we move forward with this as-is.
With regards Reinhold's assertion that Red Hat's is trying to protect JBoss Modules Llyod told InfoQ
I find it disappointing. But as I said at the time to Mark, I found it useful to use our own experiences to describe the problems we see, with the expectation that it would not be difficult to extrapolate those examples to cases. It should be clear not only from my public communications on the experts list, but also from the general community response, that the problems I am thinking about are not limited to our software but are representative of what many other framework and container authors and users are likely to encounter.
On the subject of module path names, Reinhold has also submitted an updated proposal for #AutomaticModuleNames to address the issue raised by by Robert Scholte.
#AutomaticModuleNames is a feature designed to allow developers to begin to break their own code into modules without needing to wait for all the libraries and frameworks they use to support Jigsaw.
The key part of the revised proposal is a JAR-file manifest attribute, Automatic-Module-Name, the value of which is used as the name of the automatic module defined by that JAR file when it is placed on the module path. If a JAR file on the module path does not have such a manifest attribute then its automatic-module name is computed using the existing filename-based algorithm. Reinhold suggests that
With this mechanism a library maintainer can claim a stable module name with very little effort; in Maven, e.g., a manifest attribute can be added in just a few lines of a project's 'pom.xml' file. A library maintainer can claim a stable name early, before all of the library's dependencies are modularized, which will allow libraries and applications that depend upon it to be modularized immediately.
The Java Module proposal represents a huge amout of work by Oracle over a 12 year period starting with JSR 277. Originally planned for Java 7, then 8 and now 9, it has been dogged by controversy since it started. However at this point there is, it appears, broad consensus in the community that Jigsaw does provide a much needed solution to breaking down the JDK itself. The concern is over the amount of existing Java tooling that may break if it goes into Java 9 as is.
