BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

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

Bookmarks

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:

Application.java:37: 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

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Short list of corrections

    by Christoph Engelbert,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    1. Oracle have neither started the discussion nor the Google Doc but Hazelcast (me, Greg Luck)
    2. The Google Doc doesn't state or provide any plan how to handle the situation but provides an overview of the situation
    3. Variable Handles or (VarHandles) are not meant to be a full sun.misc.Unsafe replacement but to replace the memory access features
    4. There are lots of other features which are or are not yet covered by other projects
    5. sun.misc.Unsafe is not planned to really be removed, it will always stay inside the JDK but is meant to be hidden by Jigsaw - from user's perspective this is the same as removing it

  • Re: Short list of corrections

    by Victor Grazi,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Christopher, Regarding your point 5 - If Oracle is aggressive in jigsawing modules to the point that applications start breaking unexpectedly, then even if it is the greatest thing since sliced bread it will be shunned by industry. Programming languages and politicians can't survive negative press

  • Re: Short list of corrections

    by Christoph Engelbert,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Yeah agree, just wanted to correct the fact that is does not disappear from JDK perspective but for users it looks like that.

  • Re: Short list of corrections

    by Abraham Marin-Perez,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Hi Christoph,

    Many thank for your valuable input. Please let me reply to your points following:

    1. You are correct, apologies for the misinformation. I have amended the article and the title accordingly.

    2. I guess this one is a matter of interpretation. The title of the document is “What to do about sun.misc.Unsafe?”, and it includes elements like alternatives to Unsafe or an indication of what next steps may be needed for a full replacement; this, to my eyes, looks like a plan of sorts. However, I respect the fact that you initiated the document, so given that you don’t consider this to be a plan I have removed any reference to it calling it so.

    3. You are correct, I have amended the article accordingly.

    4. I’m unsure about what you mean by this, if you provide some details I’ll be happy to follow up.

    5. I think this one is also debatable. On one side, Oracle does seem determined to remove Unsafe, although admittedly not as soon as Java 9. On the other side, if the Java Development Kit is a set of tools for developing Java applications, and taking into consideration that proprietary APIs are not meant to be used by developers, I don’t think is fair to say that Unsafe was ever part of the JDK. Perhaps it would be more correct to say that Unsafe is part (and maybe will be part) of the JRE, and that since the JRE is bundled with the JDK then it was unintentionally made available. I know this seems to be getting into the nitpicky side, but since we are talking about what is available for the developer the distinction may deem important.

  • Re: Short list of corrections

    by Christoph Engelbert,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    4. Other features that do not yet have alternatives are:
    - allocateInstance
    - defineClass / defineAnonymousClass
    - allocateMemory / reallocateMemory / freeMemory / setMemory but I'm working on a prototype for a native VarHandle (not sure though this will make it into the spec)
    - fences (store / load / full) but can be kind of simulated

  • Re: Short list of corrections

    by Abraham Marin-Perez,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Thanks Christoph, this is a very useful addition.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT