Addressing a controversy over a popular but unsupported Java API, Oracle's plans now call for making most internal APIs inaccessible by default in Java 9 while leaving a few of them still accessible.
The issue has centered around sun.misc.Unsafe, an unsupported API that has been critical to third-party Java technology developers, such as in-memory data platform provider Hazelcast, who fear that a plan to eliminate access in Java 9 would render their products unworkable. But a JEP (JDK Enhancement Proposal) posted this week calling for encapsulating most internal APIs would leave a few, including sun.misc.Unsafe, accessible in Java 9. The Java upgrade is due next year.
In an openjdk mailing list post this week, Oracle's Mark Reinhold, chief architect of the Java platform group, called encapsulation a part of the modularization of Java 9, which is the upgrade's key feature. By default, these internal APIs would not be accessible to code outside the JDK. "This change will improve the integrity of the platform, since many of these internal APIs define privileged, security-sensitive operations. In the long run it will also reduce the costs borne by the maintainers of the JDK itself and by the maintainers of libraries and applications that, knowingly or not, make use of these non-standard, unstable, and unsupported internal APIs."
Reinhold added that it was "well-known that some popular libraries make use of these internal APIs, such as sun.misc.Unsafe, to invoke methods that would be difficult, if not impossible, to implement outside of the JDK."
To ensure broad testing and adoption of the Java release, Oracle is proposing to deal with these "critical" APIs in the following manner: If there is a supported replacement in JDK 8, then it will be encapsulated; if it does not have a supported replacement in JDK 8, then it will be encapsulated in JDK 9 (Java 9), so it remains accessible to outside code. If there is a supported replacement in JDK 9, then the APIs would be deprecated in JDK 9, encapsulated, and possibly be removed in JDK 10, Reinhold said.
Hazelcast Technical Evangelist and Senior Solutions Architect Christoph Engelbert breathed a sigh of relief. "Fortunately, Oracle seems to listen to the people."
Reinhold's proposal is "interesting," said analyst John Rymer, of Forrester Research. "I think the ball is back in the third-party vendors' courts to be more specific about the impending disaster. Reinhold's response suggests that Oracle has them covered, and so where are the gaps?"
The JEP does mention some risks and assumptions of the encapsulation plan. "If some widely-used critical internal API is not identified by the time that JDK 9 is released, then applications that depend upon it will fail. The short-term workaround for such a situation would be for the end user to expose the API via the above-mentioned command-line flag; in the longer term, in a JDK 9 update release the API could be moved to the jdk.internal module and exported for external use."