11–20 of 142 posts
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.
So the explanation is: 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 And what the author takes away is: This engineer hates the Unsafe class for no reason at all. The reason the engineer hates it is that it's unsafe. Disagree with it, sure. But it's a reason, and it's a good reason (imho). I un…
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.
"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 sticking our heads in the collective sands and hoping for trivial work arounds to Unsafe is not going to work. If you're using Unsafe, this is the year to explain where the API is broken and get it straight....
"Please help us kill Unsafe, kill Unsafe dead, kill Unsafe right, and do so as quickly as possible to the ultimate benefit of everyone."
The quoted engineer understands that people use it, claims that there's no immediate risk (since Java 8 will stay around), and very very strongly implies that there is a plan to move from Unsafe to something better than Unsafe providing equivalent functionality in a stable way, and asks for help with that. Is this correct?
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…
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.
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.
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.
The argument needs to be that the use of Unsafe by these companies (or the projects listed on the blog post) both is good and has no alternatives, not that the use exists.
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.
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.
What is "Unsafe?" Is it unsafe, as its name implies? If it is unsafe, why to so many programs use it?
There's currently an effort underway to push through a variety of Java enhancement proposals that would add a lot of the unsafe functionality to the official standard library. This would enshrine the unsafe functionality as official, remove access to some of the more dangerous and less useful parts of unsafe, and would also mean that the functionality would be properly documented, which it is currently not.