Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Removal of Unsafe in Java 9 – A disaster in the making

blog.dripstat.com

Post reply on HN
Print view View original

91–100 of 142 posts

Re: Removal of Unsafe in Java 9 – A disaster in the making

#91

Post by twic »

orf wrote: post #86
jart wrote: post #34

I just read an article that says in order to even use Unsafe, you have to use reflection to unwind the stack and go searching for a reference to the Unsafe instance, because the Java authors worked so hard to make it private. So it seems to me that they'd be well within their rights to remove the class. Normally when you go to that level of epic hackery, you can't expect for official support or backwards compatibilit…

Could you provide a link to the article? I'm not saying you're wrong (I'm not a Java guy) but that sounds convoluted.

This is how you get access to Unsafe:

  Field theUnsafe = Unsafe.class.getDeclaredField("theUnsafe");
  theUnsafe.setAccessible(true);
  Unsafe unsafe = (Unsafe) theUnsafe.get(null);
Reflection, but no stack unwinding.

Re: Removal of Unsafe in Java 9 – A disaster in the making

#92

Post by pdeva1 »

geofft wrote: post #13

The quote stops short, and for someone like me who doesn't follow Java very much, it feels like it's misquoting via omission: "Let me be blunt -- sun.misc.Unsafe must die in a fire. It is -- wait for it -- Unsafe. It must go. Ignore any kind of theoretical rope and start the path to righteousness _ /now/ _. It is still years until the end of public updates to JDK 8, so we have / years /to work this out properly. But…

The post directly links to the full quote. If the intention was to misquote that would not be the case.

> there is a plan to move from Unsafe to something better than Unsafe

It is this plan and the implications of it that the post is discussing

Re: Removal of Unsafe in Java 9 – A disaster in the making

#93

Post by wtetzner »

justthistime_ wrote: post #76
danudey wrote: post #67

Earlier quoted context omitted.

It's a) unsafe, and b) an internal, undocumented API. When you start importing from sun.misc.* you've made the conscious (or ignorant) decision to write non-portable code which may well break due to any JVM release. It sucks that these people are going to have to update their code (or that end users won't be able to upgrade to Java 9 without adding special command-line flags), but it's not due to fickle Oracle develo…

Why should third-party libraries pay for Oracle's technical debt?

It's not Oracle's technical debt, it's the developers of the third-party libraries that are importing from sun.misc.*.

Re: Removal of Unsafe in Java 9 – A disaster in the making

#94

Post by pdeva1 »

geofft wrote: post #83
sreque wrote: post #69

There's a lot of backlash here against the author with comments like: "You used a sun.* package? You deserve to die in a fire as well!" These comments look like they are coming from people who have never used Unsafe. First, Unsafe provides some immensely useful features to the Java ecosystem. Second, there is no alternative to Unsafe on the JVM. That includes JNI (native code integrated within the JVM). So far, Oracl…

That link is a very useful contribution to this discussion (and possibly the first really useful comment in this thread), thanks. Everyone's entitled to their opinion, informed or not, but if you want an informed opinion, the question needs to be what the current uses of Unsafe are, why they're used, and whether there are plans for a migration path. It sort of seems like the major use case (judging from those numbers…

The document is also linked in the blog post, on the very first line...

Re: Removal of Unsafe in Java 9 – A disaster in the making

#95

Post by dsmithatx »

justthistime_ wrote: post #78
snuxoll wrote: post #21

Earlier quoted context omitted.

Backwards compatibility is only guaranteed for official Java SE and Java EE API's existing in the java.* and javax.* packages, anything in sun. , com.sun. , etc is internal to the JDK and has no such guarantees. Every time you hear of an application that only works on a specific release of the JRE you can know for sure it's because they use undocumented internal API's — keep in mind this not only impacts compatibilit…

> Stop using internal API's So what's the alternative? It's not like people are using sun.misc.Unsafe for the fun of it.

C++ and while your right, those same people were told this 17 years ago minimum by Sun, "don't use sun. classes". The other option is to keep using the old JVM. I mean I work on code all the time that require Java 6, how many people can say there Python runs on 3.x not 2.x. I'd say before anyone has to worry about Java 9 they have plenty of time to think about this problem. Add in the fact that Sun said use these at your own risk 17 years ago.

Re: Removal of Unsafe in Java 9 – A disaster in the making

#96

Post by joshstrange »

geofft wrote: post #80
justthistime_ wrote: post #77

Earlier quoted context omitted.

Java 8 support will run out in a while. I'm pretty sure it won't "be around for long enough" except if you decide to stay on unmaintained versions full of unfixed security issues.

It'll run out by September 2017, if not later: http://www.oracle.com/technetwork/java/eol-135779.html Do we believe that the affected software will not be able to move to the replacement APIs in the next two years? Honestly I'd expect that by fall 2017, the only versions of Cassandra, Spark, etc. that need sun.misc.Unsafe will themselves be unmaintained and full of unfixed security issues.

Herein lies the problem. As other commenters have pointed out there is no alternative way to do thing performantly without Unsafe. These "core" (as in used everywhere not core to java) libraries don't use Unsafe for fun but often because there is no other way to do something without compromising way too much on speed or other things. If Java 9 had replacements for Unsafe things it would be one things but it doesn't.

Re: Removal of Unsafe in Java 9 – A disaster in the making

#97

Post by twic »

karavelov wrote: post #84
vardump wrote: post #44

Earlier quoted context omitted.

It'd be unusably slow. "sun.misc.Unsafe" compiles in the instruction stream. JNI implementation would need to go through a complicated calling mechanism. I think it'd be up to 100x slower.

At least in OpenJDK it is in fact implemented as a JNI package, so it is already going through the JNI calling convention: http://hg.openjdk.java.net/jdk7/jdk7/jdk/file/9b8c96f96a0f/s...

That code shows that it's implemented as native methods, but not necessarily as JNI - these could be VM intrinsics, like Object::getClass and so on. This is the native code for Unsafe:

https://github.com/openjdk-mirror/jdk7u-hotspot/blob/master/...

It's certainly JNI-ish. Whether it is actually called via the JNI mechanism, i can't tell.

Re: Removal of Unsafe in Java 9 – A disaster in the making

#98

Post by gclaramunt »

pdeva1 wrote: post #92
geofft wrote: post #13

The quote stops short, and for someone like me who doesn't follow Java very much, it feels like it's misquoting via omission: "Let me be blunt -- sun.misc.Unsafe must die in a fire. It is -- wait for it -- Unsafe. It must go. Ignore any kind of theoretical rope and start the path to righteousness _ /now/ _. It is still years until the end of public updates to JDK 8, so we have / years /to work this out properly. But…

The post directly links to the full quote. If the intention was to misquote that would not be the case. > there is a plan to move from Unsafe to something better than Unsafe It is this plan and the implications of it that the post is discussing

Actually I don't see the post discussing anything, is just feels like "Unsafe is going away, the sky will fall!"

Re: Removal of Unsafe in Java 9 – A disaster in the making

#99

Post by taeric »

carsongross wrote: post #54
taeric wrote: post #41

Earlier quoted context omitted.

This is an odd one, though. I can not remember seeing/hearing any real issues with Unsafe. For the most part, people don't use it. There are a few that do, to ridiculous benefit. As things stand right now, without it, you can not get anything close to the performance people are seeing with it. So, what many of us are seeing here is someone is upset with basically the shape of an API. They have no evidence that I have…

puritanical I think the correct term is platonic: each of us has an Inner Platonic Engineer who cannot abide the ugliness of real world systems and insist on The Great Rewrite. A lot of progress relies on that engineer. However, in large, functioning and mature software systems he becomes the enemy.

I question just how much progress relies on that engineer. Be honest here, there are no identified problems that are being solved here. Merely an undesirable in the system that is very effective at its job.

Progress, on other hand, advances something in the way of the problem space. Not merely rearranges something in the solution space.

Re: Removal of Unsafe in Java 9 – A disaster in the making

#100

Post by scott_s »

pdeva1 wrote: post #92
geofft wrote: post #13

The quote stops short, and for someone like me who doesn't follow Java very much, it feels like it's misquoting via omission: "Let me be blunt -- sun.misc.Unsafe must die in a fire. It is -- wait for it -- Unsafe. It must go. Ignore any kind of theoretical rope and start the path to righteousness _ /now/ _. It is still years until the end of public updates to JDK 8, so we have / years /to work this out properly. But…

The post directly links to the full quote. If the intention was to misquote that would not be the case. > there is a plan to move from Unsafe to something better than Unsafe It is this plan and the implications of it that the post is discussing

The intention may not have been to misquote, but that is the effect that I saw. I had a similar reaction that geofft did when I read the whole email: it sounds like a reasonable effort to start the process of moving to something better than what is currently available. The submission here does not seem to take that into account.
Post reply on HN