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

Post by kasey_junk » Mon, Jul 13, 2015, 5:22 PM UTC

benjaminjackman wrote: post #72

vbezhenar wrote: post #60

Earlier quoted context omitted.

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

Post by geofft » Mon, Jul 13, 2015, 5:28 PM UTC

sreque wrote: post #69

There's a lot of backlash here against the author with comments like: "You used a sun.* package? You deserve to die in a fire as well!" These comments look like they are coming from people who have never used Unsafe. First, Unsafe provides some immensely useful features to the Java ecosystem. Second, there is no alternative to Unsafe on the JVM. That includes JNI (native code integrated within the JVM). So far, Oracl…

Post by dlubarov » Mon, Jul 13, 2015, 5:40 PM UTC

kasey_junk wrote: post #53

snuxoll wrote: post #3

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

The problem with that, is unlike most of the other internal classes, there is zero other way to do the things people are doing with unsafe without it. It's not a matter of expedience, it's a matter of necessity.

Post by kasey_junk » Mon, Jul 13, 2015, 5:47 PM UTC

dlubarov wrote: post #85

kasey_junk wrote: post #53

Earlier quoted context omitted.

The problem with that, is unlike most of the other internal classes, there is zero other way to do the things people are doing with unsafe without it. It's not a matter of expedience, it's a matter of necessity.

Yes, removing Unsafe would make things like PowerMock and Robolectric impossible to (re)implement. So what? Those libraries never should have been possible, and we can live without them. Languages need to be selective about what features they support, and Java was never intended to support things like mocking static methods, or creating instances without invoking any constructors.

Post by twic » Mon, Jul 13, 2015, 5:53 PM UTC

dlubarov wrote: post #85

kasey_junk wrote: post #53

Earlier quoted context omitted.

The problem with that, is unlike most of the other internal classes, there is zero other way to do the things people are doing with unsafe without it. It's not a matter of expedience, it's a matter of necessity.

Yes, removing Unsafe would make things like PowerMock and Robolectric impossible to (re)implement. So what? Those libraries never should have been possible, and we can live without them. Languages need to be selective about what features they support, and Java was never intended to support things like mocking static methods, or creating instances without invoking any constructors.