3 ms·

This is very exciting! Question for the experts out there, do you think this has the potential to do away with using the JNI in new projects for the speed boost

• teraflop 10y ago
  This change has nothing to do with JNI whatsoever. The JVM has always (well, not always, but for 15+ years) run Java code by first compiling it to native code. The only difference is that the JVM will now allow you to optionally do the compilation ahead of time, in order to decrease an application's startup overhead. This actually hurts performance of the compiled methods, since runtime profiling is not available to the AOT compiler (but the document also describes a "tiered" mode, where AOT-compiled code can be dynamically replaced with a better JIT-compiled version at runtime). If you want to link your Java code with native code written in a non-Java language, that's a totally different requirement, and JNI will continue to be the way to accomplish it.
  • pjmlp 10y ago
    > JNI will continue to be the way to accomplish it. Not on Java 10 hopefully.
  • wtetzner 10y ago
    > and JNI will continue to be the way to accomplish it. Although if you don't like JNI, you can use JNA [1] (which I believe uses JNI to link to libffi, and libffi for the rest). [1] https://github.com/java-native-access/jna https://github.com/java-native-access/jna
• the8472 10y ago
  There already are alternatives for JNI. You can use JNR[0] and JNA[1] which allow you to access native libraries by writing java. In some future version panama[2] will offer similar functionality to JNR. [0] https://github.com/jnr/jnr-ffi https://github.com/jnr/jnr-ffi [1] https://github.com/java-native-access/jna https://github.com/java-native-access/jna [2]http://openjdk.java.net/projects/panama/ http://openjdk.java.net/projects/panama/