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

131–140 of 142 posts

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

#131

Post by LoSboccacc »

ectoplasm wrote: post #129
LoSboccacc wrote: post #127

Earlier quoted context omitted.

*bad C isn't portable. and you can pack as many platform as you wish in your binary distribution, so single download still works everywhere (everywhere you built beforehand).

I think the issue is a disagreement over what portability means. To me, portability doesn't mean write once, run everywhere, it just means you can make it run on a different platform with a bit of effort. In a C/C++ program, if you're careful, you can isolate the platform-independent parts so that you only have to write them once. VM languages abstract further by creating a new language for these platform-independent…

no the issue is that while it's true that complex library accessing native stuff in c are hard to port, you don't need the whole stuff ported under jni, and here is the missing link, the functionality provided by unsafe is limited enough (think of it as a building block for higher level stuff) that it could be reasonably done in c, using posix stuff and some patching in for window which while non posix enough is at least stable trough versions.

so it basically become write twice run on many things, which is good enough.

the problem is that it's not 'rewrite all the libraries in jni' but only 'rewrite the two calls you need in jni' - scoping is relevant, as we are not arguing about jni in a vacuum.

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

#132

Post by MrBuddyCasino »

kasey_junk wrote: post #75
danudey wrote: post #67

Earlier quoted context omitted.

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

Whats wrong with:

- deprecate in Java 9

- "make it explicit to turn on" in 10, offer alternative official APIs as fallback

- remove entirely when most people have switched

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

#133

Post by vardump »

trb8 wrote: post #62
alextgordon wrote: post #57

Earlier quoted context omitted.

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?

Yes. Also there are many "safe" operations on "unsafe". Such as memory fences.

Multithreading is somewhat unsafe in general. And so is ability to do most I/O, you might overwhelm the system.

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

#134

Post by colin_mccabe »

pjmlp wrote: post #106
joshstrange wrote: post #96

Earlier quoted context omitted.

Herein lies the problem. As other commenters have pointed out there is no alternative way to do thing performantly without Unsafe. These "core" (as in used everywhere not core to java) libraries don't use Unsafe for fun but often because there is no other way to do something without compromising way too much on speed or other things. If Java 9 had replacements for Unsafe things it would be one things but it doesn't.

JNI

JNI has a very high per-call overhead. It is not an effective alternative to many things in Unsafe. For example, in Hadoop when using short-circuit local reads, the client determines if the file descriptor it has cached is still valid by doing a read from a memory-mapped file. The only way to do this with decent performance is with Unsafe#getLongVolatile. In contrast, JNI methods can't be inlined, often require copying memory back and forth, and don't work well with the just-in-time compiler.

In many cases, the overhead of JNI is too large to even use it, unless you move a large portion of the program out of Java. If Oracle goes through with this removal it will be a huge problem for Java and the JVM ecosystem.

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

#135

Post by colin_mccabe »

geofft wrote: post #13

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

I disagree that the article is "misquoting via omission." The article claims that "this engineer hates the Unsafe class for no real reason at all." The full quote which you reproduced doesn't offer any reasons for hating unsafe.

I also disagree that there is "no immediate risk." The end-of-life date for Java 8 is 2017, only 2 years from now. It can easily take a year or two to develop a product or internal tool. Would you sign off on a big new performance-critical project in Java, knowing that you might not be able to get the performance you want when these low-level APIs are removed?

Java has had a bunch of security problems in the last few years, but most of them have not been related to Unsafe at all. For example CVE-2013-0422 related to Java webapps, CVE-2013-4444 related to Tomcat, and so on. There were a bunch of bugs for POODLE and other SSL issues, similar to many other programming languages. Perhaps you could argue that CVE-2013-0422 was related to Unsafe, but since in this case it was an internal standard library class, presumably Oracle would continue to give itself permission to use whatever unsafe-equivalent they come up with.

If new APIs are needed are needed to replace uses of Unsafe, Oracle could simply add them gradually over time. This would be low-risk and easy for everyone. I can't see any reason why Unsafe needs to be "kill[ed]... as quickly as possible."

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

#136

Post by bcg1 »

pjmlp wrote: post #130
bcg1 wrote: post #120

Earlier quoted context omitted.

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.

Here, Java ONE 2014, one year ago! "Safety Not Guaranteed: sun.misc.Unsafe and the Quest for Safe Alternatives" https://www.parleys.com/tutorial/safety-not-guaranteed-sun-m... Every Java developer worth its salt knows about Java ONE.

Bet you I'm worth some salt... and I don't pay attention at all to "Java ONE"

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

#137

Post by bcg1 »

pron wrote: post #126
bcg1 wrote: post #120

Earlier quoted context omitted.

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.

They are not ignoring the result, and are doing exactly what the author wants them to do, except they started doing it before this hysterical piece was written.

I kind of figured as much... and that was my point actually... that writing and whining about it useless, and that if they actually do start misbehaving the community has the capability to take real action.

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

#138

Post by trb8 »

vardump wrote: post #133
trb8 wrote: post #62

Earlier quoted context omitted.

Yes. Also there are many "safe" operations on "unsafe". Such as memory fences.

Multithreading is somewhat unsafe in general. And so is ability to do most I/O, you might overwhelm the system.

Sure. Unsafe in terms of program correctness. By that measure, new Thread() is unsafe.

But that's not a reasonable definition of "unsafe". This could crash the JVM is a reasonable definition. And fences and ordered instructions cannot.

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

#139

Post by scubaguy »

I read this article yesterday and I really dislike how it is worded. The "this engineer" has a name, Donald Smith, this is what he said:

"If you're using Unsafe, this is the year to explain where the API is broken and get it straight.... Please help us kill Unsafe, kill Unsafe dead, kill Unsafe right, and do so as quickly as possible to the ultimate benefit of everyone."

It reads like a request to have a discussion on Unsafe, to talk about it and find solutions. Unfortunately, I don't see anyone pointing out why Unsafe should be kept around on that thread (http://mail.openjdk.java.net/pipermail/openjfx-dev/2015-Apri...).

And this quote from Oracle shows an effort to do things right:

http://mail.openjdk.java.net/pipermail/discuss/2013-October/... "This is definitely something we plan to propose for SE 9. I expect to see a JEP from the current maintainers of sun.misc.Unsafe..."

This (http://blog.codefx.org/java/dev/how-java-9-and-project-jigsa...) seems like a more balanced article on the situation.

"So far we focused on the problematic aspects of Project Jigsaw. But that should not divert from the exciting and – I think – very positive nature of the planned changes. After reading the documents, I am impressed with the scope and potential of this upcoming Java release. While it is likely not as groundbreaking for individual developers as Java 8, it is even more so for everyone involved in building and deploying – especially of large monolithic projects." near future. (This is far too small to require a whole JSR.)"

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

#140

Post by valarauca1 »

geofft wrote: post #114
valarauca1 wrote: post #111

Earlier quoted context omitted.

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

You are. Here's a great idea, if you've never implemented a JVM don't tell somebody how it works.

Java VM isn't native code. Serialized objects are "Field"(s) within the JVM. Which is short hand for a "Growable Page File" more or less. Which starts at a fixed 32bit address. How does that work? JVM implementation takes care of that, so you decide.

On top of that whats inside the Field itself doesn't actually matter to anyone provided the same read/write opcodes do the right thing(s).

The serialization process starts by jumping to your initial field, copying the serialized data into another buffer. While checking integrity, and assuring that your data conforms to the serialization standard b/c its in memory representation doesn't. The fun part is when ever it encounters a RetAddr type it has to jump to that Field, and serialize THAT Field also, as that Field is part of the object your serializing. Of course you don't actually know whats in the Field without consulting its ClassField which gives you a basic prototype of what-is-where.

Furthermore what ever optimizations the JIT makes, it'll end up treating Fields more-or-less like stack frames. So you have to keep an active record of how it'll mangle memory, so you know how to untangle that when you want to do serialization.

Understand now?

Post reply on HN