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

21–30 of 142 posts

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

#21

Post by snuxoll »

jryan49 wrote: post #14
pron wrote: post #6

Chill. There is no disaster in the making. Oracle is very much aware of the issue, and is actually already taking the very same steps suggested by the author. It has assembled a public working group that is coming up with a spec for a public "Unsafe" API[1] (that is safer than Unsafe). In the meantime , use of Unsafe in Java 9 will be possible with a command-line flag in order to allow the working group more time to…

The point is if you have to pass a flag to allow the use of Unsafe, you're breaking "works-out-of-the-box" backwards compatibility.

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 compatibility with other releases of OpenJDK/Oracle JDK, but the sun.* API's are not typically part of third-party JVM's like JRockit or the IBM JVM.

Stop using internal API's and then bitching when Oracle makes changes to them, you only have yourself to blame.

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

#24

Post by jryan49 »

pron wrote: post #19
jryan49 wrote: post #14

Earlier quoted context omitted.

The point is if you have to pass a flag to allow the use of Unsafe, you're breaking "works-out-of-the-box" backwards compatibility.

"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…

I agree in most cases that it's perfectly reasonable. But from a pragmatic position, I think this needs to be treated as a special case because of all the people that are using it. I still like the idea of having a flag that opts people in to using internal classes. It's like an agreement almost that they know what they're doing is not supported across versions.

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

#25

Post by LoSboccacc »

xxpor wrote: post #11
ZitchDog wrote: post #7

Entire companies exist around functionality provided in Unsafe. I don't see this going well if they remove it without providing access to the functionality it gives. Java has plenty of problems, but backward compatibility over the years has been simply amazing. This would chip away at one of the few legitimate reasons to use Java in 2015.

sun.* has ALWAYS been exempt from that guarantee though.

yeah they went the fast and cheap route instead of doing the right thing, and they are now going to be bitten by it, and they can go cry a river for all that I care.

those are the sloppy engineers that are holding back evolution of software at large, from little things like obscure functions to huge operating systems like http://blogs.msdn.com/b/oldnewthing/archive/2005/07/28/44439...

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

#26

Post by smacktoward »

snuxoll wrote: post #21
jryan49 wrote: post #14

Earlier quoted context omitted.

The point is if you have to pass a flag to allow the use of Unsafe, you're breaking "works-out-of-the-box" backwards compatibility.

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.

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

#27

Post by jryan49 »

snuxoll wrote: post #21
jryan49 wrote: post #14

Earlier quoted context omitted.

The point is if you have to pass a flag to allow the use of Unsafe, you're breaking "works-out-of-the-box" backwards compatibility.

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…

Sorry I wasn't clear enough in saying that I agree with you here in most cases. But since Unsafe is used in so many applications that it should probably be an exception to this rule for now. That a better solution is to create a public API, then keep track of popular projects as they move to it. When it's moved then enable the flag.

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

#29

Post by snuxoll »

pron wrote: post #19
jryan49 wrote: post #14

Earlier quoted context omitted.

The point is if you have to pass a flag to allow the use of Unsafe, you're breaking "works-out-of-the-box" backwards compatibility.

"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.
Post reply on HN