Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

blog.dripstat.com

Post reply on HN
Print view View original

51–60 of 142 posts

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

#51

Post by carsongross »

xg15 wrote: post #33
carsongross wrote: post #4

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

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.

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

#53

Post by kasey_junk »

snuxoll wrote: post #3
ante_annum wrote: post #2

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.

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.

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

#54

Post by carsongross »

taeric wrote: post #41
xg15 wrote: post #33

Earlier quoted context omitted.

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.

This is an odd one, though. I can not remember seeing/hearing any real issues with Unsafe. For the most part, people don't use it. There are a few that do, to ridiculous benefit. As things stand right now, without it, you can not get anything close to the performance people are seeing with it. So, what many of us are seeing here is someone is upset with basically the shape of an API. They have no evidence that I have…

puritanical

I think the correct term is platonic: each of us has an Inner Platonic Engineer who cannot abide the ugliness of real world systems and insist on The Great Rewrite. A lot of progress relies on that engineer.

However, in large, functioning and mature software systems he becomes the enemy.

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

#55

Post by kasey_junk »

[deleted] wrote: post #49
syjer wrote: post #46

Earlier quoted context omitted.

1. it's quite likely that the Unsafe classes will be accessible with a flag, so for this kind of projects it's not really a big problem, as they provide the shell scripts for launching the jvm with all the necessary parameters.

[deleted]

If you are using Unsafe in your code you have already decided that you know what jvm you are deploying to.

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

#56

Post by kasey_junk »

vbezhenar wrote: post #47

Why libraries need Unsafe, after all? What problems does it solve for them?

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 it for is being rolled into documented/standard libraries and this is just the migration pains coming out.

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

#57

Post by alextgordon »

Daneel_ wrote: post #38
dikaiosune wrote: post #20

Earlier quoted context omitted.

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.

Reading this thread as C programmer has me scratching my head.

Of course you have to resort to low-level functionality to achieve performance. That's how computers work. We can't all live in fuzzy wuzzy land.

Surely Unsafe is safer than writing the whole thing in C and using JNI?

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

#58

Post by jlarocco »

[deleted] wrote: post #49
syjer wrote: post #46

Earlier quoted context omitted.

1. it's quite likely that the Unsafe classes will be accessible with a flag, so for this kind of projects it's not really a big problem, as they provide the shell scripts for launching the jvm with all the necessary parameters.

[deleted]

> The problem is for more then a decade companies were told this problem would never exist.

That's exactly opposite of the truth.

The Sun and Oracle documentation has always said (back to at least the Java 1.1 days) that internal APIs could change or disappear at any time, and explicitly said not to use classes in sun.* unless you wanted to fix your code with every new JDK release.

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

#59

Post by jakevn »

Daneel_ wrote: post #38
dikaiosune wrote: post #20

Earlier quoted context omitted.

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.

This sort of practice is present in the implementation of every mainstream programming language. 'Unsafe' operations are the bread and butter of computation.

As far as use in libraries, you wont get the same performance without it in most of the places it is used. This is much like Python's 'unsafe' use of C modules for performance.

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

#60

Post by vbezhenar »

kasey_junk wrote: post #56
vbezhenar wrote: post #47

Why libraries need Unsafe, after all? What problems does it solve for them?

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.

Post reply on HN