Reg comments9

Oracle hatches 'incubator' OpenJDK APIs idea

Unfinished APIs in JDK and Java SE

Bees hatch out of honeycomb wedged bwteen wooden bench slats. Photo by Shutterstock

Experimental and unfinished Java APIs could soon appear in new versions of Java under a plan from Oracle.

So-called Incubator Modules have been proposed as a means of inserting promising features into the OpenJDK.

OpenJDK is an open-source implementation and reference implementation of Java Standard Edition.

Modules would contain "Incubating APIs" that would eventually become standardized, made final in a next release or removed entirely, Oracle said.

Oracle defines Incubator APIs as something “under development for eventual inclusion in the Java SE Platform, or JDK, but [which] is not yet sufficiently proven.”

Their inclusion would - according to Oracle - reduce the chance for “costly mistakes in the Java SE Platform”.

“Many Java SE Platform or JDK APIs would benefit from spending short period of time in a JDK Release Project prior to being standardized in the JCP,” Oracle said in its proposal to other members of the Java community here.

Oracle believes this would mean greater opportunity to test new APIs outside the immediate OpenJDK community, generating feedback before an API is finished or dropped.

The Incubator APIs plan comes from Chris Hegarty, a member of Oracle’s technical staff, and was tabled in November and updated in January.

Incubator APIs were discussed at the Java Community Processes governing Executive Committee meeting in January and is expected to come up again. JCP EC members are understood to be assessing the Incubator Modules.

Oracle’s proposal, however, has alarmed some JCP members.

Fragmentation

The Reg has seen discussions between Oracle Java Platform Group chief architect and OpenJDK chair Mark Reinhold and JCP members who are concerned at a possible fragmentation of the Java standard that might occur with Incubator APIs.

APIs could become get overlooked and de-factor embedded in the OpenJDK, JDK and Java SE, becoming non-standard features to Java.

Re-inforcing this, devs might build their applications using the unfinished APIs. Their apps could also end up broken should they adopt Incubator APIs that are subsequently retired.

JCP executive committee member and Hazelcast chief executive Greg Luck, in conversation with The Reg, echoed the concerns of others.

“How do you prevent Java fragmentation? What happens if people start using the OpenJDK? If it’s there, people will start wiring code against it,” Luck said.

In one JCP discussion thread seen by The Reg, Reinhold dismissed the idea of fragmentation, saying it “isn’t really an issue” because incubator APIs would “have a finite lifetime and can change or even disappear without any notice at all”.

According to JDK Enhancement Proposal (JEP) 11, incubator modules would be packaged into jmod files with a --do-not-resolve-by-default option so use is on an opt-in basis. Oracle believes the opt-in nature would avoid users becoming dependent on modules with warnings also issued of or when they are removed.

However, there is a concern, too, over the way Incubator Modules have been proposed – the idea is from Oracle, not the community it seems.

Luck said while he’s not opposed to the idea of Incubator APIs: “The problem... is this idea seems to have come from nowhere - no discussion on JCP mailing lists.

Luck called this a “further example” of the JEP 11 idea “getting further away from the JCP process.

The full proposal is for JEP 11: Incubator Modules. JEPs were introduced by Oracle in 2011 as a parallel arrangement to the more familiar Java Specification Requests (JSRs), shortly after Oracle bought Sun Microsystems and thereby took on stewardship of Java.

JEPs are used to propose, implement or track new features in the OpenJDK.

Concern has also arisen over Oracle’s plan to début Incubator APIs in JDK 9 after the latter had been signed off as feature-complete in May 2016.

Reinhold told one OpenJDK mailing thread that “the plan”, if JEP 11 was approved, would be to integrate JEP 110 and refactor JEP 282 as an experimental plug-in for JDK 9.

JEP 110 is for a new HTTP client API that implements HTTP/2 and WebSocket to legacy HttpURLConnection APIs, while JEP 282 is a plug-in mechanism for modules and dependencies. ®


Biting the hand that feeds IT © 1998–2017