InfoQ has previously reported on the developing situation regarding JSR 376 - the Java Platform Module System, commonly called "Project Jigsaw". Now, in a highly unusual move, IBM and Red Hat have both publicly announced that they will vote "no" on Jigsaw in its current form.

This project is an attempt to provide a standardised module system for Java, and after having been initially scheduled for Java 7, it was moved to Java 8 after Mark Reinhold announced Plan B. In July 2012, Oracle further delayed the project, by moving it to Java 9. Even this schedule was subject to slippage, due to the complexity of Jigsaw and the need for extensive testing.

The scope of Jigsaw is impressive, intending not only to modularise the monolithic Java runtime, but to also enforce strong encapsulation, so that Java code is forced to only access platform libraries via their public interfaces. Modular code may not simply reach into the internals of another module.

Not only that, but Oracle intends for the module system to be used by application code as well as the JDK itself. To this end, the JSR 376 Expert Group (the EG) has been discussing all aspects of application-level modularity as well as the JDK.

Outside of the standardisation process, there are already two main module implementations that have some overlap with the scope of Jigsaw: JBoss Modules, from Red Hat, and OSGi, which is looked after by a consortium of vendors, but includes IBM.

Both of these vendors are members of the 25-member Java Community Process Executive Committee, which is the body that must approve all new Java standards, including those which make up the "platform releases", i.e. major Java versions. Such releases must be approved by a 2/3 majority.

Announcing their decision on the OpenJDK mailing list Tim Ellison from IBM made this comment:

IBM is also voting "no" which 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.

Ellison's post appears to be a reply to a potentially private exchange between Ellison, Mark Reinhold and Scott Stark (Red Hat). Stark’s comment was:

As it stands, Red Hat will not vote for the approval of this public review draft of JPMS as it is not in the best interest of the Java community.

At issue is the difficulty of making the existing modules systems supplied by IBM and Red Hat interoperate cleanly with Jigsaw. However, neither system is dominant in the market, and whilst painful for those affected, the majority of Java projects would not be affected by these incompatibilities.

However, the problems with Jigsaw extend further than just OSGi and JBoss modules. The dominant code packaging and distribution system in the Java world is Maven. Jigsaw does not provide a clean upgrade path for Maven-based projects to move from the packaging of code into JAR files to modules.

The detailed concerns are presented in a joint document authored by both Red Hat and external Maven experts. The key Maven concern is known as "Automatic Modules", and for many in the community the situation as regards Maven is potentially far worse than the compatibility problems with either of the extant vendor module systems.

Martijn Verburg, leader of the London Java Community (and also a voting member on the JCP Executive Committee) told InfoQ that:

It's unusual for an EC member to state their voting presence this early and in such a public manner. It is indicative of the serious concerns that the major players in the Java ecosystem have about JPMS and the de-facto Jigsaw implementation. Although the module specification and the implementation to date provides Java with some major security and compact runtime improvements, it has not (yet) bridged the gaps with other common module systems and build tools that sit upon it, rightly or wrongly raising fears of a Python2/3 style split for the Java platform.

For there to be such open disagreement and outright hostility to a new Java version so late in the development cycle is completely unprecedented. Whilst this vote is only the Public Review Ballot and not the final ratification ballot, this is a clear warning shot.

Oracle's published timeline for the delivery of Java 9 appears to be on a collision course with the expressed view of other vendors and the community. It remains to be seen whether they will alter direction, potentially delaying Java 9 yet again or to force through their vision of modular Java, even over the objections of major vendors and community participants.