Will Java 9 release be delayed? Red Hat, IBM to cast explicit vote against JSR

Java Development Kit 9 had its planned release for July 27.

By Zee Media Bureau | Updated: May 11, 2017, 13:01 PM IST
Will Java 9 release be delayed? Red Hat, IBM to cast explicit vote against JSR

New Delhi: Oracle Chief Java Architect Mark Reinhold has lashed out at Red Hat, IBM for their declaration that they will cast an “explicit vote against” Java Specification Request (JSR).

Java Development Kit 9 had its planned release for July 27. However, with the latest turns of events, it is leading to speculations that the decision might delay the release of Java 9 beyond July.

Meanwhile Reinhold in an open letter to the Java Community wrote, “Red Hat Middleware initially agreed to the goals and requirements of the JSR, but then worked consistently to undermine them. They attempted to turn this JSR into something other than it was intended to be. Rather than design one module system that is both approachable and scalable they instead wanted to design a “meta” module system via which multiple different module systems could interoperate on an intimate basis. I can only assume that they pursued this alternate goal in order to preserve and protect their home-grown, non-standard module system, which is little used outside of the JBoss/Wildfly ecosystem.”

“IBM’s recent position appears rooted in a vague desire for “closer consensus” amongst EG members. I would prefer more consensus too, but that is not possible given Red Hat Middleware’s position. I can only conclude that IBM has decided that their interests are best served by delaying this JSR and, also, JSR 379 (Java SE 9)—which is regrettable,” his blog further stated.

“Is the present Specification for this JSR perfect? No, of course not. It does, however, reflect years of development, testing, and refinement with active feedback from many developers.,” he wrote.

Reinhold further added, “Could we make the Specification better if we spent more time on it? Yes, of course we could. What we have now does not solve every practical modularity-related problem that developers face, but it meets the agreed goals and requirements and is a solid foundation for future work. It is time to ship what we have, see what we learn, and iteratively improve. Let not the perfect be the enemy of the good.”