Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News The Community Initiates Discussion to Work Around the Removal of sun.misc.Unsafe

The Community Initiates Discussion to Work Around the Removal of sun.misc.Unsafe

This item in japanese

The community has started discussions around what to do about sun.misc.Unsafe. Despite being part of an unsupported, proprietary API, this class is widely used by a number of popular tools due to its ability to provide low-level access to memory management. Given that Oracle has indicated their desire to remove this class at some point, developers are looking for viable alternatives.

Since the release of Java 6, the java compiler was modified to warn the developer whenever a class that is part of a proprietary API is being used. Proprietary API classes are not covered by the OpenJDK definition, which means that these classes can be modified or removed at any moment without any prior warning; moreover, since they aren’t covered by the Java TCK, these classes are not guaranteed to be available in all different implementations of the JVM, or if they are, to behave in an equivalent manner. In other words, developers are generally discouraged from using these classes at all: warning: Unsafe is internal proprietary API
and may be removed in a future release

The problem with sun.misc.Unsafe is that it provides a number of functionalities that aren’t available through any of the standard classes available in OpenJDK. This has led library authors to use this class despite the warnings in order to achieve things like atomic memory operations, fast interaction with native code or off-heap memory access, just to name a few. Spring, Mockito, and the java.util.concurrent library are examples of tools that make use of Unsafe and that would therefore be impacted by this change. By extension, any Java application that makes use of any of these tools or libraries (surely the vast majority of applications) is indirectly impacted by this.

The current state of the discussion, which is still in progress at the time of writing this article, includes alternatives for both the short term and longer term.

In the longer term, Variable Handles are meant to be a supported replacement for sun.misc.Unsafe operations upon object fields and array elements. This means that, although Variable Handles won’t be a full replacement for Unsafe, it will be enough for some uses cases. Variable Handles are currently under development through JEP 193 and targeted to be available for Java 9, however, there are concerns among community members on whether a full implementation will be ready by the Java 9 feature-complete deadline (November 2015). Even if a full implementation becomes available on time, library authors wouldn’t be able to port their applications from Unsafe to VarHandles until the next version of Java is released (unless they start working against the development version of Java 9, which not everybody is expected to do), which creates the need of a shorter term solution.

For the shorter term, Oracle’s plan is for Unsafe not to be removed, but rather hidden through the new modules system, to be available in Java 9; access to the class could still be obtained, although the actual mechanism is still being discussed. As an example, one of the current suggestions is that proprietary APIs, Unsafe among them, are made accessible by passing a particular flag in the command line; this would work with tools that provide their own launching scripts, since the script could be updated to include the flag and the end user could remain unaware of the changes, but is not likely to represent a solution for tools that are used by the developers who launch the application themselves.

The potential impact of the proposal and the uncertainty around the possible solutions has triggered a number of heated debates among the community. This is not an uncommon reaction to fundamental changes though, for instance, similar debates arose after Oracle’s proposal to make G1 the default Garbage Collector; in that case, Oracle accepted to reach a middle point and added a back-up plan to revert the change if G1’s performance wasn’t satisfactory.

Correction: 2nd August 2015

This article incorrectly described the initiative around what to do about sun.misc.Unsafe as being driven by Oracle, and Variable Handles as a full replacement for Unsafe. In reality, the initiative is driven by community members, and Variable Handles will only be a partial replacement for Unsafe.

Rate this Article