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

111–120 of 142 posts

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

#111

Post by valarauca1 »

geofft wrote: post #64
valarauca1 wrote: post #48

Earlier quoted context omitted.

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

> As there is no alternative to unsafe serialization in terms of performance. It goes without saying. I don't think that's true, though perhaps I don't understand what you mean by "unsafe serialization". First, I suspect one can use JNI and get at least as good performance. There are other tradeoffs, like the ease of packaging, but in order to evaluate those we need a clear problem statement. Second, premature optimi…

Seeing as you've admitted you don't understand what I'm talking about. Here is some reading material:

http://www.javacodegeeks.com/2010/07/java-best-practices-hig...

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

#112

Post by MichaelGG »

pjmlp wrote: post #103
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…

Except that those of us on the Java community that follow Java development are fully aware of the 2014 survey, done by Oracle about how Unsafe is being used and what is our opinion on it. Of course, many HNers that hate Java aren't aware of those discussions and post comments without knowing the full background.

What is the purpose of enforcing module boundaries? That appears to be why none of these internal classes will be accessible. Outside of a sandboxed environment, who cares what you do? Is it for some magic optimization? Or just some folks on a rampage? (The quote from the guy saying it needs to die, and I read the mailing list, well it seems to be baseless.)

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

#113

Post by MichaelGG »

dikaiosune wrote: post #20
ihuman wrote: post #5

What is "Unsafe?" Is it unsafe, as its name implies? If it is unsafe, why to so many programs use it?

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…

Why remove it though? What harm is being caused?

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

#114

Post by geofft »

valarauca1 wrote: post #111
geofft wrote: post #64

Earlier quoted context omitted.

> As there is no alternative to unsafe serialization in terms of performance. It goes without saying. I don't think that's true, though perhaps I don't understand what you mean by "unsafe serialization". First, I suspect one can use JNI and get at least as good performance. There are other tradeoffs, like the ease of packaging, but in order to evaluate those we need a clear problem statement. Second, premature optimi…

Seeing as you've admitted you don't understand what I'm talking about. Here is some reading material: http://www.javacodegeeks.com/2010/07/java-best-practices-hig...

Thanks, I definitely understand this topic imperfectly -- I am familiar with high-performance serialization, but I'm not familiar with Java or best practices with doing this sort of thing in Java. So it's definitely helpful for you to be clear in what you're discussing and what Unsafe is currently used for.

Is the specific Unsafe use here to serialize a Java object into a byte array? The linked article doesn't describe using Unsafe, so I'm still not sure what functions are at issue.

This is what I was referring to about a bounds-checked buffer in my parent comment: it seems like you could state that accesses to an area of memory are unsafe and unchecked, except to check that the reads/writes are within the buffer. This preserves safety for the JVM as a whole, but gets you native performance within the buffer. Intel MPX should be able to implement this efficiently, and the standard techniques in other languages for efficient bounds-checked memory access should all apply.

Am I completely off-base here?

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

#115

Post by mike_hearn »

MichaelGG wrote: post #112
pjmlp wrote: post #103

Earlier quoted context omitted.

Except that those of us on the Java community that follow Java development are fully aware of the 2014 survey, done by Oracle about how Unsafe is being used and what is our opinion on it. Of course, many HNers that hate Java aren't aware of those discussions and post comments without knowing the full background.

What is the purpose of enforcing module boundaries? That appears to be why none of these internal classes will be accessible. Outside of a sandboxed environment, who cares what you do? Is it for some magic optimization? Or just some folks on a rampage? (The quote from the guy saying it needs to die, and I read the mailing list, well it seems to be baseless.)

There are documents and presentations discussing that.

Yes, it has a variety of benefits, including security, performance (e.g. a static linker with DCE becomes a lot easier), not exposing internal guts to apps that then come to depend on them, etc.

All that said, if you want to disable module enforcement, then they seem to be saying there will be command line switches to do that. Much like there are switches to disable other forms of rule enforcement.

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

#116

Post by dlubarov »

kasey_junk wrote: post #87
dlubarov wrote: post #85

Earlier quoted context omitted.

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.

Without the current unsafe package most performance sensitive applications (whether throughput, latency, or pause sensitive) will have no recourse to meet their current performance levels. That will leave people to choose between staying on Java 8, worse (and often unacceptable) performance, and migrating to a different language. At this point, there is a very good chance if your library/application is known for perf…

With some effort, I'm sure the folks behind Cassandra, Hadoop etc. could achieve acceptable performance with allocateDirect(). It doesn't support explicit freeing, but you can always reuse buffers and write your code to allocate slices within them.

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

#117

Post by pjmlp »

MichaelGG wrote: post #112
pjmlp wrote: post #103

Earlier quoted context omitted.

Except that those of us on the Java community that follow Java development are fully aware of the 2014 survey, done by Oracle about how Unsafe is being used and what is our opinion on it. Of course, many HNers that hate Java aren't aware of those discussions and post comments without knowing the full background.

What is the purpose of enforcing module boundaries? That appears to be why none of these internal classes will be accessible. Outside of a sandboxed environment, who cares what you do? Is it for some magic optimization? Or just some folks on a rampage? (The quote from the guy saying it needs to die, and I read the mailing list, well it seems to be baseless.)

One of the purposes of Jigsaw is offering a way to define a public API based on multiple jar files, similar to what OSGi does.

Similar in concept how Assembly Modules work in .NET, with friendly internals, which incidentally not many devs know about.

In Java's case a linker will be part of the SDK, so that only the Java code required for a given application will be deployed.

Since Oracle needed to clean up dependencies to implement Jigsaw, they are taking the opportunity to also remove most internal APIs, Unsafe being one of them.

They are also in the process of replacing JNI with something more programming friendly, P/Invoke style, but it will only come in Java 10.

There is also the reason that in a memory safe language every use of JNI and Unsafe is another security bug waiting to happen. If the compiler/runtime are able to offer safe APIs with similar performance, then those exploits can be avoided.

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

#119

Post by LoSboccacc »

Someone1234 wrote: post #68
LoSboccacc wrote: post #25

Earlier quoted context omitted.

yeah they went the fast and cheap route instead of doing the right thing, and they are now going to be bitten by it, and they can go cry a river for all that I care. those are the sloppy engineers that are holding back evolution of software at large, from little things like obscure functions to huge operating systems like http://blogs.msdn.com/b/oldnewthing/archive/2005/07/28/44439...

You forgot to explain what the "right thing" that they should be doing is? Even according to most articles on the topic there is very to any pleasant alternatives that are cross platform e.g. https://dzone.com/articles/understanding-sunmiscunsafe

jni, and don't tell me now that c isn't portable.

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

#120

Post by bcg1 »

pjmlp wrote: post #104
bcg1 wrote: post #101

Earlier quoted context omitted.

If the author is correct (which I am not questioning or doubting) and very high profile projects are using this feature... and Oracle refuses solicit input from the community... those developers with clout can and should maintain a fork of OpenJDK to include this feature. If things like Netty only run on the forked version of the JDK, and the developers are committed to not porting or working around a lack of Unsafe…

Oracle did a survey last year exactly as input for what to do.

Good, that seems like a smart move. It is of course possible for them to still ignore the results of that survey, or to game the results, or that a majority of respondents don't care or understand the issue anyhow. My point is that if this feature is important enough to people, they can take real action and don't have to kiss the ring and beg at the feet of power in order to achieve the result that they want.
Post reply on HN