Java 9 won’t be released on July 27 after all.
Oracle has proposed that Java 9 Standard Edition be delayed until September so the open source community that is finalizing Java 9 can address the ongoing controversy over a planned but later rejected approach to modularity, said Georges Saab, vice president of software development in the Java platform group at Oracle and chairman of the OpenJDK governing board.
The Java Platform Module System, a key capability of Java Development Kit 9 and the subject of Java Specification Request (JSR) 376, failed in a vote by the Java executive committee earlier this month. IBM, Red Hat, and Twitter, among others, voted against the plan, because they believed it would be too disruptive to developers and would fragment the Java community.
The measure was sent back to the proposal’s expert group for further discussion. Since then, the group has reached consensus on addressing the modularity concerns, Saab said. But they cannot rework Java 9 in time for the original July 27 release date.
Once the committee submits the revised JSR 376 to the executive committee for approval, there will be a two-week revoting period on JSR 376. This proposal features technology known as Project Jigsaw that centers on the module system intended to make Java more scalable.
If the revised JSR 376 approved, as expected, work can proceed on implementing it in the official version of Java 9 SE.
This setback for Java 9s upcoming upgrade, however, should just be temporary, with Oracle expecting a more rapid cadence of Java SE releases going forward, Saab said. “What that means is that, in the past, if a particular feature for instance did not make it into [Java] 9, people might be concerned that it would then take several years to get to the point where it could be addressed.” But more frequent releases, annually or even more frequently than that, increases the number of opportunities to add features and reduces wait times, said Saab.
To ease migration to Java 9’s new modularity approach, Mark Reinhold, Oracle’s chief Java architect, proposed illegal reflective access, which would allow this access by default in the release while disallowing it in future releases. Although Reinhold’s proposal will not address all migration concerns, it will change the migration from one huge step to smaller steps spread across multiple releases.
The JSR 376 expert group has also tackled several other modularity issues such as #VersionSyntax, to revise the syntax of module version strings to handle a wider variety of version-string schemes. In this case, the panel decided to retain the existing API. An issue left open was the #ModuleIdentifiers proposal, for handling multiple versions of modules of the same name. This issue will be negotiated at a later date.