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

101–110 of 142 posts

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

#101

Post by bcg1 »

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…

If the author is correct (which I am not questioning or doubting) and very high profile projects are using this feature... and Oracle refuses solicit input from the community... those developers with clout can and should maintain a fork of OpenJDK to include this feature. If things like Netty only run on the forked version of the JDK, and the developers are committed to not porting or working around a lack of Unsafe support, Oracle will be forced to reconcile with the community or risk burning down their own house.

Do not be surprised if they remove this feature from the GPL'd OpenJDK but maintain an analogous feature in their proprietary JRockit JVM. There is a good chance that this is a "shot heard around the world", and now is the time to start fighting back.

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

#102

Post by scott_s »

pdeva1 wrote: post #94
geofft wrote: post #83

Earlier quoted context omitted.

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...

It was not obvious to me that the other side of that link would be a living document on current uses of Unsafe.

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

#103

Post by pjmlp »

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…

Except that those of us on the Java community that follow Java development are fully aware of the 2014 survey, done by Oracle about how Unsafe is being used and what is our opinion on it.

Of course, many HNers that hate Java aren't aware of those discussions and post comments without knowing the full background.

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

#104

Post by pjmlp »

bcg1 wrote: post #101
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…

If the author is correct (which I am not questioning or doubting) and very high profile projects are using this feature... and Oracle refuses solicit input from the community... those developers with clout can and should maintain a fork of OpenJDK to include this feature. If things like Netty only run on the forked version of the JDK, and the developers are committed to not porting or working around a lack of Unsafe…

Oracle did a survey last year exactly as input for what to do.

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

#106

Post by pjmlp »

joshstrange wrote: post #96
geofft wrote: post #80

Earlier quoted context omitted.

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.

JNI

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

#107

Post by pjmlp »

snuxoll wrote: post #29
pron wrote: post #19

Earlier quoted context omitted.

"Works-out-of-the-box" backwards compatibility -- without flags -- has never been guaranteed (even the default GC is about to change), let alone for non-public classes. Whenever you compile a class that uses Unsafe you get a warning (that you can't disable!) that says "this class may go away at any time". Still the reality is recognized, and you'll still be able to use Unsafe -- despite all warnings -- and all you ne…

Thankfully, Project Jigsaw (if it lands) in JDK9 should remove the problem of internal classes entirely — they simply won't be available to use.

It already did. Java 9 early alphas are available.

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

#108

Post by MichaelGG »

smacktoward wrote: post #26
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…

This is exactly the same line Microsoft took when they broke poorly architected applications with the new (and much better!) security model in Vista. "You're the one who wrote an app that needlessly requires root privileges, you have only yourself to blame." It... didn't go well.

And MS did a lot of work to detect such apps and make them work OK. What's the real argument against Unsafe? People are upset that it exists? Really?

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

#109

Post by vardump »

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...

I think these are a strong hint they're not truly JNI:

Line 61:

  * 
 Most methods in this class are very low-level, and correspond to a
  * small number of hardware instructions (on typical machines).  Compilers
  * are encouraged to optimize these methods accordingly.
Line 90:

  /// peek and poke operations
  /// (compilers should optimize these to memory ops)

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

#110

Post by dlubarov »

twic wrote: post #89
dlubarov wrote: post #85

Earlier quoted context omitted.

Yes, removing Unsafe would make things like PowerMock and Robolectric impossible to (re)implement. So what? Those libraries never should have been possible, and we can live without them. Languages need to be selective about what features they support, and Java was never intended to support things like mocking static methods, or creating instances without invoking any constructors.

We can live without Robolectric? How do we write tests for Android code without it?

Turn on unitTests.returnDefaultValues, write some mockable wrappers around core classes like SystemClock, unit test what you can, and write instrumentation tests for everything else.

An increasing number of teams are moving away from Robolectric anyway, since it's so complex and buggy, and there are some things it will never properly support such as COLLATE LOCALIZED.

Post reply on HN