5 ms·

But a new model should be that: a new model, not a suicide pact. Wise engineers keep the old API working while offering the new API (which, soon enough, will a

But a new model should be that: a new model, not a suicide pact. Wise engineers keep the old API working while offering the new API (which, soon enough, will acquire its own gronkiness.) See the x86 and OS9/OSX evolutions, for example. Thinking about the domain problem in the abstract is smart. Thinking about the current system in practical terms is wise.

geofft 11y ago
Java 8 is still around, and will be around for long enough. It's the Classic to your Cocoa, and the analogy works well: you need a full, separate virtual machine, because the software could be doing unsafe things with memory that you don't want to affect modern apps, but that VM will be around for a few years. The equivalent of Carbon in this analogy is software written to documented APIs, which will run on both Java <= 8 and Java 9.
- justthistime_ 11y ago
  Java 8 support will run out in a while. I'm pretty sure it won't "be around for long enough" except if you decide to stay on unmaintained versions full of unfixed security issues.
  - geofft 11y ago
    It'll run out by September 2017, if not later: http://www.oracle.com/technetwork/java/eol-135779.html http://www.oracle.com/technetwork/java/eol-135779.html Do we believe that the affected software will not be able to move to the replacement APIs in the next two years? Honestly I'd expect that by fall 2017, the only versions of Cassandra, Spark, etc. that need sun.misc.Unsafe will themselves be unmaintained and full of unfixed security issues.
    - joshstrange 11y ago
      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.
      - pjmlp 11y ago
        JNI
        colin_mccabe 11y ago
        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.

geofft 11y ago

Java 8 is still around, and will be around for long enough. It's the Classic to your Cocoa, and the analogy works well: you need a full, separate virtual machine, because the software could be doing unsafe things with memory that you don't want to affect modern apps, but that VM will be around for a few years. The equivalent of Carbon in this analogy is software written to documented APIs, which will run on both Java <= 8 and Java 9.

justthistime_ 11y ago
Java 8 support will run out in a while. I'm pretty sure it won't "be around for long enough" except if you decide to stay on unmaintained versions full of unfixed security issues.
- geofft 11y ago
  It'll run out by September 2017, if not later: http://www.oracle.com/technetwork/java/eol-135779.html http://www.oracle.com/technetwork/java/eol-135779.html Do we believe that the affected software will not be able to move to the replacement APIs in the next two years? Honestly I'd expect that by fall 2017, the only versions of Cassandra, Spark, etc. that need sun.misc.Unsafe will themselves be unmaintained and full of unfixed security issues.
  - joshstrange 11y ago
    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.
    - pjmlp 11y ago
      JNI
      - colin_mccabe 11y ago
        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.