nav search
Data Center Software Security Transformation DevOps Business Personal Tech Science Emergent Tech Bootnotes BOFH

Oracle crushed in defeat as Java world votes 'No' to modular overhaul

Dire warnings ignored, plea for unity heard

By Gavin Clarke, 12 May 2017

Oracle has suffered an embarrassing setback in its plans for a modular architecture in Java 9.

The database goliath has lost a Java Community public-review ballot by 13 to 10 that was to have approved its Java Platform Module System (JPMS) specification as a final draft. Executive Committee members ignored dire warnings from Oracle spec lead Mark Reinhold in an open letter where he claimed that a “no” vote would not only delay Java 9 but also be a “vote against the Java Community Process itself”.

The JSR, number 376, needed a two-thirds majority to pass.

In that bluntly worded letter, Oracle’s Java platform chief also chastised IBM and Red Hat for suggesting that they might vote against JPMS.

In discussion threads, both had voiced long-running concerns to JPMS.

Reinhold singled out Red Hat in particular, suggesting it had been motivated by a desire to protect its own “non-standard” module system.

IBM and Red Hat were among the 13 who ignored Reinhold’s warnings, and have now voted to stop the current incarnation of JPMS.

The hope is that EC members will work together before a follow-on vote, within the next 30 days, to resolve outstanding technical agreements.

However, it took Executive Committee member and fellow “no” voter SAP to pull up the Oracle Java chief while also calling for unity.

SAP wrote of its decision: “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!”

SAP also criticised a growing tension between the OpenJDK JEP and JSR processes, and a “lack of direct communication within the expert group.”

JDK Enhancement Proposals (JEPs) were introduced by Oracle in 2011 and are used to propose, implement or track new features in the OpenJDK. They are a parallel arrangement to the more familiar Java Specification Requests (JSRs) SAP said it has been unclear which parts of JPMS are considered mere implementation details and which are part of the standard specification.

Explaining its vote, IBM called on the Expert Committee members to address the outstanding issues in JPMS. “IBM would like to see closer consensus among the entire Expert Group before this specification proceeds to the next step.”

In his open letter, Reinhold dismissed consensus, saying it was not a mandated part of the JCP, which gives spec leads like him “broad powers” to prevent Expert Group members “from obstructing progress in order to defend their narrow interests.”

Red Hat’s middleware team, meanwhile, re-iterated their concerns that in its current form, JPMS would break existing Java Enterprise Edition code.

They were backed by Twitter, which also cast a “no” vote, and wrote: "Our main concern is that it is likely that this JSR will prove disruptive to Java developers, while ultimately not providing the benefits that would be expected of such a system."

Explaining its vote, Red Had said that it had raised “several issues” within the Executive Group list before hand but they had been rejected. It criticised “insufficient consensus” on changes that would have an “equally dramatic impact on the Java communities. It also slammed a “lack of openness on receiving and discussing community input”.

Red Hat called for a “more considered evaluation” of all input saying consensus gathering “should not take too much time” and would produce something that would be better received. ®

The Register - Independent news and views for the tech community. Part of Situation Publishing