Still using Java in 2015 – A disaster in the making
Removal of Unsafe in Java 9 – A disaster in the making
71–80 of 142 posts
Re: Removal of Unsafe in Java 9 – A disaster in the making
#72Earlier quoted context omitted.
It's almost entirely about performance. Unsafe allows you access to concurrent intrinsics as well as memory layout functions. It's true that it is widely used, but the people that use it also understood the ramifications of using it. If you were trying to make jvm agnostic code you didn't use it. If you were trying to make code that could run on a variety of jvm versions, you didn't use it. A lot of what people use i…
Why those concurrent intrinsics are not available with "safe" code? They are not compatible with Java Memory Model? They are not implemented at some platforms? What's so unsafe about concurrent primitives? There is API in java.util.concurrent.atomic, for example. I understand that Unsafe is used for direct access to memory, but why this direct access is needed? May be there are other ways to solve those problems.
AFAIK there aren't other ways to get the performance required to be competitive in the financial space. People that are using these libraries don't want to use undocumented, Unsafe code. However, their hands are forced given the races they are competing in. They could switch to C++ but that's not really a great option for firms that have java code bases going back 10+ years.
Plus, personally, and for a lot of others, the jvm plus a dash of sun.misc.Unsafe, is a lot better than going over to C++.
More concretely, Here are two sets of trading libraries that use unsafe for direct memory access: https://github.com/real-logic/simple-binary-encoding https://github.com/OpenHFT (various libraries in here use it, once you drink the Unsafe Kool-aid it's hard to turn back from the performance benefits you obtain).
If Oracle just rips off the Unsafe band-aid without a replacement, the business decision for these firms is still sound. They will just stay on 8 and start making migration plans (likely to the C++ bandwagon).
However, It sounds like Oracle plans to give a sane alternative which is good and what everyone using Unsafe would prefer (along with deprecating it the meantime to give them some time to adapt).
One real world example: The CME (Chicago Mercantile Exchange) reworked the entire way they distributed market data (v3 of their Market Data Protocol) to mirror the cutting edge in performance oriented serialization libraries (e.g. Cap'n Proto). They also commissioned an Open Source library for parsing that data (real-logic SBE), it uses unsafe to approach the performance of C++ code.
Re: Removal of Unsafe in Java 9 – A disaster in the making
#73Why on Earth is it a big deal that you need to pass a flag to the JVM at startup?
I understand that backwards compatibility is valued, but if I went to my CTO and said "we're gonna drop Java 9 in production, and we're not gonna test beforehand"...the reaction would not be pretty.
Re: Removal of Unsafe in Java 9 – A disaster in the making
#74This is related and unrelated and maybe even meta to some degree:
There are a couple of companies that are guilty of using their free software update mechanism to try and trick people into installing crap they don't want (and might even mess-up their systems): Sun and Adobe.
I almost happened to me last night as I updated Flash on a test system and some bullshit anti-virus crap-ware was going to be installed because I was moving fast and neglected to un-check the check-box on the site. I was able to stop the install process and start over. No harm done.
These companies need public shaming to stop using this bullshit method to make a few more bucks. Are they so hard-up that they need to trick users to install crap to make money? I sure hope not.
Sun, Adobe, please STOP trying to trick users into installing crap-ware they were not looking for in the first place.
Re: Removal of Unsafe in Java 9 – A disaster in the making
#75Earlier quoted context omitted.
That is a pretty crappy explanation, on the engineer's side. To be clear, any explanation that is not immediately followed with examples to how current valid uses of Unsafe can be accomplished without it, are simply witch hunts by an engineer that hasn't had to meet the same requirements.
It's a) unsafe, and b) an internal, undocumented API. When you start importing from sun.misc.* you've made the conscious (or ignorant) decision to write non-portable code which may well break due to any JVM release. It sucks that these people are going to have to update their code (or that end users won't be able to upgrade to Java 9 without adding special command-line flags), but it's not due to fickle Oracle develo…
You quite simply have NO option to do on the JVM most of the things people are using unsafe for in Java 9/10 without a migration plan from Oracle.
What Oracle is close to "hey all you performance sensitive folks, we aren't going to support unsafe anymore, can you tell us what you are using it for and how we can migrate to that explicitly?"
It just so happens that one of the leading proposals is "leave in java 9 but make it explicit to turn on". This is probably the right way to do this (in my opinion) but it does have the downside of making neither camp happy (it leaves unsafe so the purists are mad, and it causes headaches for people using unsafe).
Re: Removal of Unsafe in Java 9 – A disaster in the making
#76Earlier quoted context omitted.
That is a pretty crappy explanation, on the engineer's side. To be clear, any explanation that is not immediately followed with examples to how current valid uses of Unsafe can be accomplished without it, are simply witch hunts by an engineer that hasn't had to meet the same requirements.
It's a) unsafe, and b) an internal, undocumented API. When you start importing from sun.misc.* you've made the conscious (or ignorant) decision to write non-portable code which may well break due to any JVM release. It sucks that these people are going to have to update their code (or that end users won't be able to upgrade to Java 9 without adding special command-line flags), but it's not due to fickle Oracle develo…
Why should third-party libraries pay for Oracle's technical debt?
Re: Removal of Unsafe in Java 9 – A disaster in the making
#77Earlier quoted context omitted.
But a new model should be that: a new model, not a suicide pact. Wise engineers keep the old API working while offering the new API (which, soon enough, will acquire its own gronkiness.) See the x86 and OS9/OSX evolutions, for example. Thinking about the domain problem in the abstract is smart. Thinking about the current system in practical terms is wise.
Java 8 is still around, and will be around for long enough. It's the Classic to your Cocoa, and the analogy works well: you need a full, separate virtual machine, because the software could be doing unsafe things with memory that you don't want to affect modern apps, but that VM will be around for a few years. The equivalent of Carbon in this analogy is software written to documented APIs, which will run on both Java…
Java 8 support will run out in a while.
I'm pretty sure it won't "be around for long enough" except if you decide to stay on unmaintained versions full of unfixed security issues.
Re: Removal of Unsafe in Java 9 – A disaster in the making
#78Earlier 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…
> 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.
Re: Removal of Unsafe in Java 9 – A disaster in the making
#79The 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…
Here is the link to the full quote.
http://mail.openjdk.java.net/pipermail/openjfx-dev/2015-Apri...
Re: Removal of Unsafe in Java 9 – A disaster in the making
#80Earlier quoted context omitted.
Java 8 is still around, and will be around for long enough. It's the Classic to your Cocoa, and the analogy works well: you need a full, separate virtual machine, because the software could be doing unsafe things with memory that you don't want to affect modern apps, but that VM will be around for a few years. The equivalent of Carbon in this analogy is software written to documented APIs, which will run on both Java…
Java 8 support will run out in a while. I'm pretty sure it won't "be around for long enough" except if you decide to stay on unmaintained versions full of unfixed security issues.
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.