Hacker News Reader

Comment by jryan49 | Hacker News Reader

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.

View on HN

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.

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

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?

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

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.

"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 need to do is add a flag. I think that's very reasonable.

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.

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.

Reply on news.ycombinator.com