4 ms·

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 li

by sreque 11y ago

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, Oracle has stated their intent to remove Unsafe from Java 9. To all the users of Unsafe, Oracle is basically saying, "tell us your use cases for Unsafe, and if we decide they are valid we may try to create an alternative for you. If you're lucky, we may even ship that alternative in Java 9 or 10! Have a nice day!" Many people, myself included, find this unacceptable. For instance, it looks like several groups are currently collaborating on a document discussing uses cases for Unsafe and whether alternative features satisfying those use cases are expected to appear in Java 9: https://docs.google.com/document/d/1GDm_cAxYInmoHMor-AkStzWvwE9pw6tnz_CebJQxuUE/edit?pli=1 https://docs.google.com/document/d/1GDm_cAxYInmoHMor-AkStzWv... As you can see, the majority of the cells in the column "Expected in Java 9" flat out say "no". There is a good reason people are up in arms about the removal of this API. Personally, if I had to choose between Oracle keeping Unsafe and Oracle implementing Java 8 Lambdas, I would have picked Unsafe in a heartbeat. At the end of the day, Lambdas are mostly syntactic sugar, especially in their current implementation. Unsafe, on the other hand, actually empowers you to do something more.

geofft 11y ago
That link is a very useful contribution to this discussion (and possibly the first really useful comment in this thread), thanks. Everyone's entitled to their opinion, informed or not, but if you want an informed opinion, the question needs to be what the current uses of Unsafe are, why they're used, and whether there are plans for a migration path. It sort of seems like the major use case (judging from those numbers) is reading and writing raw byte buffers, possibly mapped from other objects/files, with native performance. Is there a potential sensible design for a bounds-checked raw data API ("unsafe but only within these pages") that maintains the JVM's usual safety guarantees for all other data, and can be implemented in a performant way?
- pdeva1 11y ago
  The document is also linked in the blog post, on the very first line...
  - scott_s 11y ago
    It was not obvious to me that the other side of that link would be a living document on current uses of Unsafe.
bcg1 11y ago
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 support, Oracle will be forced to reconcile with the community or risk burning down their own house. Do not be surprised if they remove this feature from the GPL'd OpenJDK but maintain an analogous feature in their proprietary JRockit JVM. There is a good chance that this is a "shot heard around the world", and now is the time to start fighting back.
- pjmlp 11y ago
  Oracle did a survey last year exactly as input for what to do.
  - bcg1 11y ago
    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.
    - pron 11y ago
      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.
      - bcg1 11y ago
        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.
pjmlp 11y ago
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.
- MichaelGG 11y ago
  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.)
  - mike_hearn 11y ago
    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.
  - pjmlp 11y ago
    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.

by sreque 11y ago

geofft 11y ago

That link is a very useful contribution to this discussion (and possibly the first really useful comment in this thread), thanks. Everyone's entitled to their opinion, informed or not, but if you want an informed opinion, the question needs to be what the current uses of Unsafe are, why they're used, and whether there are plans for a migration path. It sort of seems like the major use case (judging from those numbers) is reading and writing raw byte buffers, possibly mapped from other objects/files, with native performance. Is there a potential sensible design for a bounds-checked raw data API ("unsafe but only within these pages") that maintains the JVM's usual safety guarantees for all other data, and can be implemented in a performant way?

pdeva1 11y ago
The document is also linked in the blog post, on the very first line...
- scott_s 11y ago
  It was not obvious to me that the other side of that link would be a living document on current uses of Unsafe.

bcg1 11y ago

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 support, Oracle will be forced to reconcile with the community or risk burning down their own house. Do not be surprised if they remove this feature from the GPL'd OpenJDK but maintain an analogous feature in their proprietary JRockit JVM. There is a good chance that this is a "shot heard around the world", and now is the time to start fighting back.

pjmlp 11y ago
Oracle did a survey last year exactly as input for what to do.
- bcg1 11y ago
  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.
  - pron 11y ago
    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.
    - bcg1 11y ago
      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.

pjmlp 11y ago

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.

MichaelGG 11y ago
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.)
- mike_hearn 11y ago
  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.
- pjmlp 11y ago
  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.