Document it, make it public. It's very much needed!
Removal of Unsafe in Java 9 – A disaster in the making
31–40 of 142 posts
Re: Removal of Unsafe in Java 9 – A disaster in the making
#32Earlier 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."
And lo and behold, a decade later everyone has sucked it up and done the right thing. Sure, there were growing pains, but it was for the best and in hindsight everyone can agree with that.
Sometimes the boot just has to come down, for better and for worse, everyone will adapt and life will continue.
Re: Removal of Unsafe in Java 9 – A disaster in the making
#33Once again, The Platonic Engineer gazes hatefully at the gronky, ugly and awkward things that make things work in real life, rub his hands together and says... "Burn it to the ground."
Or you could actually stop for a second and find out why your current model needs so many ugly and awkward workarounds and try to adjust it accordingly - which seems to be what Oracle is trying to do in the long term.
Re: Removal of Unsafe in Java 9 – A disaster in the making
#34I 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 compatibility. So the author of this article using scare tactics to keep that feature seems rather disingenuous.
Re: Removal of Unsafe in Java 9 – A disaster in the making
#35Many people seem to be upset with Oracle, but I think they should be upset with the vendors who ship applications/libraries that depend on the "sun.*" packages.
Oracle (then Sun) have since _1998_ strongly discouraged the use of them: https://web.archive.org/web/19980215011039/http://java.sun.c...
Re: Removal of Unsafe in Java 9 – A disaster in the making
#36What about shipping sun.misc.Unsafe as 3rd party package? Is there anything in it that can't be done as through JNI?
No, you can do everything in Unsafe via JNI, but that comes with all the disadvantages of JNI (including .dll's and .so's is not so easy for a fat-jar deployment).
Re: Removal of Unsafe in Java 9 – A disaster in the making
#37The 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…
Yes you are.
Re: Removal of Unsafe in Java 9 – A disaster in the making
#38What is "Unsafe?" Is it unsafe, as its name implies? If it is unsafe, why to so many programs use it?
It's part of the OpenJDK/Oracle VM implementation, not an official part of the Java standard library. It allows for all sorts of fun stuff like native compare and swap operations (used for concurrent collections iirc), object allocation without calling the constructor, accessing blocks of memory directly without object references, and other things. The reason it's called unsafe is because it allows developers to bypa…
Thanks for the thorough explanation - you summarised the issue well, as well as explaining the impact and flow on effects.
I have to say, I agree with the engineer.. I'm cringing just knowing this sort of practice is seen as acceptable, and it reinforces my distaste for Java. If you have to resort to insecure practices to achieve performance, there's something wrong with the framework.
Re: Removal of Unsafe in Java 9 – A disaster in the making
#39> Oracle plans to remove sun.misc.Unsafe in Java 9. This is an absolute disaster in the making and has the potential to completely destroy the entire ecosystem around Java. You know your language has a problem if the entire ecosystem threatens to fall apart as soon as you actually try to enforce the language's conceptual model and try to make use of the guarantees it provides.
With the caveat that you need to believe in the hyperbole of a chicken running around with its head cut off.
Re: Removal of Unsafe in Java 9 – A disaster in the making
#40Earlier quoted context omitted.
In addition, it's in the sun.misc package, if it's not in java.* or javax.* it is ripe for pruning, you'd think people would have learned by now to stop using internal classes since pretty much every JRE/JDK release known to mankind has changed them or removed them.
It's sort of amazing that the diatribe here is against Oracle for wanting to remove an undocumented internal API because of typesafety, and not against the open source projects that use a specifically unsafe, undocumented internal API. I mean, nothing against these projects -- I understand that type safety can carry a performance penalty -- but the anger of this article is amazing.
The issues is 2 fold for people.
1) People use Apache Storm and Cassandra daily. These need Unsafe to function at current performance changing its functionality may change these tools. This can be considered existiential threat to their job.
2) The one big selling point of the JVM is that JVM 1.0 code will run in JVM 8.0 without issue, and often much faster. With this change that isn't necessarily true, and potientally when your .jar was compile will weigh on which JVM is used or HOW that jvm is started.