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

41–50 of 142 posts

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

#41

Post by taeric »

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.

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 seen of trouble caused by it. Only a desire that such things not exist. This feels almost puritanical in how it is being exercised. Which is just plain silly for a technical debate.

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

#42

Post by geofft »

valarauca1 wrote: post #40
ante_annum wrote: post #12

Earlier quoted context omitted.

It's sort of amazing that the diatribe here is against Oracle for wanting to remove an undocumented internal API because of typesafety, and not against the open source projects that use a specifically unsafe, undocumented internal API. I mean, nothing against these projects -- I understand that type safety can carry a performance penalty -- but the anger of this article is amazing.

The issues is 2 fold for people. 1) People use Apache Storm and Cassandra daily. These need Unsafe to function at current performance changing its functionality may change these tools. This can be considered existiential threat to their job. 2) The one big selling point of the JVM is that JVM 1.0 code will run in JVM 8.0 without issue, and often much faster. With this change that isn't necessarily true, and potiental…

1. Have the maintainers of Storm, Cassandra, etc. said whether they architecturally need Unsafe in its current form, and whether the replacement APIs under development will fulfill their needs?

There's a lot of software out there that uses MD5 or DES right now. Saying that the software needs MD5 or DES is a different claim entirely.

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

#43

Post by taeric »

geofft wrote: post #17
ZitchDog wrote: post #7

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 existed around DOS extenders and TSRs. Microsoft rearchitected and everyone is better off for it. 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.

There should be some argument made that the use by these companies is causing trouble, as well. DOS had real identifiable reasons not to use it. The rhetoric used so far just has Unsafe upsetting some engineers for existing.

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

#44

Post by vardump »

karavelov wrote: post #30

What about shipping sun.misc.Unsafe as 3rd party package? Is there anything in it that can't be done as through JNI?

It'd be unusably slow. "sun.misc.Unsafe" compiles in the instruction stream. JNI implementation would need to go through a complicated calling mechanism. I think it'd be up to 100x slower.

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

#45

Post by vbezhenar »

valarauca1 wrote: post #40
ante_annum wrote: post #12

Earlier quoted context omitted.

It's sort of amazing that the diatribe here is against Oracle for wanting to remove an undocumented internal API because of typesafety, and not against the open source projects that use a specifically unsafe, undocumented internal API. I mean, nothing against these projects -- I understand that type safety can carry a performance penalty -- but the anger of this article is amazing.

The issues is 2 fold for people. 1) People use Apache Storm and Cassandra daily. These need Unsafe to function at current performance changing its functionality may change these tools. This can be considered existiential threat to their job. 2) The one big selling point of the JVM is that JVM 1.0 code will run in JVM 8.0 without issue, and often much faster. With this change that isn't necessarily true, and potiental…

About #2: there are many internal changes even between minor releases and if you relying on those internals, your code is NOT portable.

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

#46

Post by syjer »

valarauca1 wrote: post #40
ante_annum wrote: post #12

Earlier quoted context omitted.

It's sort of amazing that the diatribe here is against Oracle for wanting to remove an undocumented internal API because of typesafety, and not against the open source projects that use a specifically unsafe, undocumented internal API. I mean, nothing against these projects -- I understand that type safety can carry a performance penalty -- but the anger of this article is amazing.

The issues is 2 fold for people. 1) People use Apache Storm and Cassandra daily. These need Unsafe to function at current performance changing its functionality may change these tools. This can be considered existiential threat to their job. 2) The one big selling point of the JVM is that JVM 1.0 code will run in JVM 8.0 without issue, and often much faster. With this change that isn't necessarily true, and potiental…

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.

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

#48

Post by valarauca1 »

geofft wrote: post #42
valarauca1 wrote: post #40

Earlier quoted context omitted.

The issues is 2 fold for people. 1) People use Apache Storm and Cassandra daily. These need Unsafe to function at current performance changing its functionality may change these tools. This can be considered existiential threat to their job. 2) The one big selling point of the JVM is that JVM 1.0 code will run in JVM 8.0 without issue, and often much faster. With this change that isn't necessarily true, and potiental…

1. Have the maintainers of Storm, Cassandra, etc. said whether they architecturally need Unsafe in its current form, and whether the replacement APIs under development will fulfill their needs? There's a lot of software out there that uses MD5 or DES right now. Saying that the software needs MD5 or DES is a different claim entirely.

>Have the maintainers of Storm, Cassandra, etc. said whether they architecturally need Unsafe in its current form [...] ?

As there is no alternative to unsafe serialization in terms of performance. It goes without saying.

>There's a lot of software out there that uses MD5 or DES right now. Saying that the software needs MD5 or DES is a different claim entirely.

I agree, but you are putting the trees before the forest.

Saying implementation X is flawed is one thing. Saying We are removing implementation X and offering no alternatives is another. While there are plan to offer an alternative, they are simply plans not an immidate alternative, thus a problem. When DES/MD5 were removed it was clear that they were already inferior implementations, and superior alternatives existed. That isn't true for java.

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

#49

Post by [deleted] »

syjer wrote: post #46
valarauca1 wrote: post #40

Earlier quoted context omitted.

The issues is 2 fold for people. 1) People use Apache Storm and Cassandra daily. These need Unsafe to function at current performance changing its functionality may change these tools. This can be considered existiential threat to their job. 2) The one big selling point of the JVM is that JVM 1.0 code will run in JVM 8.0 without issue, and often much faster. With this change that isn't necessarily true, and potiental…

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]

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

#50

Post by mbreese »

valarauca1 wrote: post #40
ante_annum wrote: post #12

Earlier quoted context omitted.

It's sort of amazing that the diatribe here is against Oracle for wanting to remove an undocumented internal API because of typesafety, and not against the open source projects that use a specifically unsafe, undocumented internal API. I mean, nothing against these projects -- I understand that type safety can carry a performance penalty -- but the anger of this article is amazing.

The issues is 2 fold for people. 1) People use Apache Storm and Cassandra daily. These need Unsafe to function at current performance changing its functionality may change these tools. This can be considered existiential threat to their job. 2) The one big selling point of the JVM is that JVM 1.0 code will run in JVM 8.0 without issue, and often much faster. With this change that isn't necessarily true, and potiental…

On #2 - Java 1 code using the public API (java.*) will run in Java 8. Using internal APIs was never considered forward compatible.
Post reply on HN