6 ms·

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 a

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 bypass a lot of the safety guarantees that java is supposed to provide as a memory managed language. But it's useful for getting more performance out of the VM. There's currently an effort underway to push through a variety of Java enhancement proposals that would add a lot of the unsafe functionality to the official standard library. This would enshrine the unsafe functionality as official, remove access to some of the more dangerous and less useful parts of unsafe, and would also mean that the functionality would be properly documented, which it is currently not.

Daneel_ 11y ago
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.
- alextgordon 11y ago
  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?
  - trb8 11y ago
    Yes. Also there are many "safe" operations on "unsafe". Such as memory fences.
    - vardump 11y ago
      Multithreading is somewhat unsafe in general. And so is ability to do most I/O, you might overwhelm the system.
      - trb8 11y ago
        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.
  - Daneel_ 11y ago
    I completely agree - I have no problem with leveraging low-level functionality, but there's usually a safe and and unsafe way to approach it - and from what I've read 'unsafe' doesn't take the secure approach. (separately: why the downvote? I get downvoted for having the opinion that it's worth a tiny bit of performance for improved security?)
- jakevn 11y ago
  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.
  - dikaiosune 11y ago
    As a corollary, many Java programs rely really heavily on very thick layers of abstraction (in my day-to-day on a multi-node "enterprise" Java app I regularly see stack traces of 200-500 function calls), and it's important to keep each slice of those abstractions as thin as possible. As another reply pointed out, much better to do some hinky things with the JVM then to call out through the native interface every time you need high performance for a tight loop.
MichaelGG 11y ago
Why remove it though? What harm is being caused?
- dikaiosune 11y ago
  I haven't seen anything official about it, but I imagine it's been planned for some time. Sun/Oracle have explicitly warned against its use for a while. It seems less necessary when GC improvements in the last two releases have meant it's much easier to get great speed and latency with idiomatic and documented implementations. Further, what performance improvements are offered by Unsafe are obtained by breaking a variety of Java's guarantees, and I imagine that it is tiresome as an OpenJDK dev to hear about bugs "caused by the JVM" in libraries that depend on an unsupported undocumented API. Just speculation, of course.

Daneel_ 11y ago

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.

alextgordon 11y ago
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?
- trb8 11y ago
  Yes. Also there are many "safe" operations on "unsafe". Such as memory fences.
  - vardump 11y ago
    Multithreading is somewhat unsafe in general. And so is ability to do most I/O, you might overwhelm the system.
    - trb8 11y ago
      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.
- Daneel_ 11y ago
  I completely agree - I have no problem with leveraging low-level functionality, but there's usually a safe and and unsafe way to approach it - and from what I've read 'unsafe' doesn't take the secure approach. (separately: why the downvote? I get downvoted for having the opinion that it's worth a tiny bit of performance for improved security?)
jakevn 11y ago
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.
- dikaiosune 11y ago
  As a corollary, many Java programs rely really heavily on very thick layers of abstraction (in my day-to-day on a multi-node "enterprise" Java app I regularly see stack traces of 200-500 function calls), and it's important to keep each slice of those abstractions as thin as possible. As another reply pointed out, much better to do some hinky things with the JVM then to call out through the native interface every time you need high performance for a tight loop.

MichaelGG 11y ago

Why remove it though? What harm is being caused?

dikaiosune 11y ago
I haven't seen anything official about it, but I imagine it's been planned for some time. Sun/Oracle have explicitly warned against its use for a while. It seems less necessary when GC improvements in the last two releases have meant it's much easier to get great speed and latency with idiomatic and documented implementations. Further, what performance improvements are offered by Unsafe are obtained by breaking a variety of Java's guarantees, and I imagine that it is tiresome as an OpenJDK dev to hear about bugs "caused by the JVM" in libraries that depend on an unsupported undocumented API. Just speculation, of course.