5 ms·

I'm not a Java dev, so forgive me if I misunderstand it, but is this basically just a different API for calling C functions? Java already was able to do so was

I'm not a Java dev, so forgive me if I misunderstand it, but is this basically just a different API for calling C functions? Java already was able to do so was it not? How does this improve on it?

Racing0461 3y ago
I was interested in why also since there was already JNI. This is what i found >>> The FFM API allows Java programs to interoperate safely and more easily with code and data outside the Java runtime. Unlike JNI, which often involves brittle and error-prone boilerplate code, the FFM API aims to provide a more straightforward and safer method for calling native libraries and manipulating native data.
- TeMPOraL 3y ago
  That sounds like a zero-information marketing blurb, though. The interesting bits would be not the claims, but how they're realized - i.e. how FFM is implemented and what's the difference between how it works and how the implementation is different from JNI.
  - kaba0 3y ago
    They have low-overhead temporal-, spatial-, and thread- safety guarantees. Spatial in that every “C pointer”=MemorySegment is associated with bounds, which is checked at runtime. Temporal, in that such a MemorySegment has a scope (usually created in a try-with resource block, being closed right afterwards, or alternatively at a random later point, up to the GC), outside of which it can’t be called (also, freeing actions can be associated with these). Thread safety, in that a scope also determines the availability of a given segment to other threads (must be explicitly specified to be accessible mutably from multiple threads).
simtel20 3y ago
I am not a java dev either, but as it's named, this focuses on memory and ffi,and e.g. in the linked message talks about passing heap memory to a foreign function in a zero copy manner, which sounds like a great trick which would make a lot of calling c APIs from java much easier and faster.
mwilliamson 3y ago
The JEP itself has a motivation section, including issues with the existing mechanism for interop with C, JNI: https://openjdk.org/jeps/454 https://openjdk.org/jeps/454
fweimer 3y ago
If you want to use JNI to interface with an existing C library, you need to write a thin C or C++ wrapper that is called via JNI and interfaces with that C library. This new Java API allows you to call C functions directly and manipulate data structures on the C side, too. It's also possible to create a C function pointer for a Java method, to enable callbacks/upcalls from C.
- dkersten 3y ago
  JNA exists which already let you do that. What does this change or add over JNA? https://en.m.wikipedia.org/wiki/Java_Native_Access https://en.m.wikipedia.org/wiki/Java_Native_Access
  - thayne 3y ago
    Well for one thing, it is part of OpenJDK, instead of a third party library built on top of JNI, and can thus, at least in theory, integrate better with the runtime.
  - MrBuddyCasino 3y ago
    JNI: fast but tedious JNA: comfortable but slow Panama: comfortable & fast
    - matheusmoreira 3y ago
      What is it about JNA that makes it slow? What is it about Panama that makes it fast? Soon I'll start working on similar features for my own language. This could give me a massive head start.
      - pjmlp 3y ago
        Panama is part of the runtime, it can be made to make the best use of that knowledge. JNA relies on JNI, and exposes a better Java interface.
      - fweimer 3y ago
cstrahan 3y ago
JNI allows one to write C code that bridges the gap between the Java VM and existing C libraries. That C code must be compiled, and must follow some rather tedious patterns (regarding method signatures and other little details). It’s a bit of a pain to write and compile, if all you want to do is quickly call some function from an existing C library. Also, because symbol resolution is done at compile-time, this is a non starter for something like JRuby, wherein one would want to write plain Ruby code to call a C function — rather than writing Ruby, Java and JNI flavored C code. Ruby is an interpreted language, so calling into or out of C requires dynamic symbol resolution, and for the C->Ruby callback case, a closure must be created on the fly (that is, a C ABI function must be JIT compiled for that method or proc). This isn’t particular to Ruby — any interpreted language will run into this issue on the JVM (picture Python and its ctypes and/or cffi libraries). You can see some of the hoops that JRuby had to jump through to support this use case, in order to provide a JRuby implementation of the ‘ffi’ gem interface: https://javadoc.io/doc/org.jruby/jruby-core/9.2.13.0/org/jruby/ext/ffi/FFI.html https://javadoc.io/doc/org.jruby/jruby-core/9.2.13.0/org/jru... https://www.igvita.com/2009/01/15/bridging-mri-jruby-rubinius-with-ffi/ https://www.igvita.com/2009/01/15/bridging-mri-jruby-rubiniu... It’s been a minute, so my recollection may be wrong, but IIRC JRuby uses Java and JNI to call into a C shim that then calls into libffi to handle things like creating C ABI conforming closures and such on the fly (the ffi gem on CRuby also uses libffi for the same purposes). Correction: I believe JRuby uses JNA, which in turn is Java+JNI to call C that then calls into libffi, which is then leveraged to call whatever other functions (or create C callbacks back into the JVM). So I’m pretty sure FFM would be an officially supported replacement (maybe superset?) of JNA. (I’m on vacation and typed all of this out on my phone, so forgive me if I got some details a bit off) I’m pretty sure that just about all of that complexity can be ripped out once FFM is generally available.
- headius 3y ago
  You know a lot about JRuby's use of FFI! One correction though, JRuby uses a reimplementation of jna called jnr, which is generally much faster (close to jni for simple calls). We are working with folks on the FFM team to re-implement the core jnr back end. It's very exciting work, and I will present it this weekend at RubyConf Taiwan!

I'm not a Java dev, so forgive me if I misunderstand it, but is this basically just a different API for calling C functions? Java already was able to do so was it not? How does this improve on it?

Racing0461 3y ago

I was interested in why also since there was already JNI. This is what i found >>> The FFM API allows Java programs to interoperate safely and more easily with code and data outside the Java runtime. Unlike JNI, which often involves brittle and error-prone boilerplate code, the FFM API aims to provide a more straightforward and safer method for calling native libraries and manipulating native data.

TeMPOraL 3y ago
That sounds like a zero-information marketing blurb, though. The interesting bits would be not the claims, but how they're realized - i.e. how FFM is implemented and what's the difference between how it works and how the implementation is different from JNI.
- kaba0 3y ago
  They have low-overhead temporal-, spatial-, and thread- safety guarantees. Spatial in that every “C pointer”=MemorySegment is associated with bounds, which is checked at runtime. Temporal, in that such a MemorySegment has a scope (usually created in a try-with resource block, being closed right afterwards, or alternatively at a random later point, up to the GC), outside of which it can’t be called (also, freeing actions can be associated with these). Thread safety, in that a scope also determines the availability of a given segment to other threads (must be explicitly specified to be accessible mutably from multiple threads).

simtel20 3y ago

I am not a java dev either, but as it's named, this focuses on memory and ffi,and e.g. in the linked message talks about passing heap memory to a foreign function in a zero copy manner, which sounds like a great trick which would make a lot of calling c APIs from java much easier and faster.

mwilliamson 3y ago

The JEP itself has a motivation section, including issues with the existing mechanism for interop with C, JNI: https://openjdk.org/jeps/454 https://openjdk.org/jeps/454

fweimer 3y ago

If you want to use JNI to interface with an existing C library, you need to write a thin C or C++ wrapper that is called via JNI and interfaces with that C library. This new Java API allows you to call C functions directly and manipulate data structures on the C side, too. It's also possible to create a C function pointer for a Java method, to enable callbacks/upcalls from C.

dkersten 3y ago
JNA exists which already let you do that. What does this change or add over JNA? https://en.m.wikipedia.org/wiki/Java_Native_Access https://en.m.wikipedia.org/wiki/Java_Native_Access
- thayne 3y ago
  Well for one thing, it is part of OpenJDK, instead of a third party library built on top of JNI, and can thus, at least in theory, integrate better with the runtime.
- MrBuddyCasino 3y ago
  JNI: fast but tedious JNA: comfortable but slow Panama: comfortable & fast
  - matheusmoreira 3y ago
    What is it about JNA that makes it slow? What is it about Panama that makes it fast? Soon I'll start working on similar features for my own language. This could give me a massive head start.
    - pjmlp 3y ago
      Panama is part of the runtime, it can be made to make the best use of that knowledge. JNA relies on JNI, and exposes a better Java interface.
    - fweimer 3y ago

cstrahan 3y ago

JNI allows one to write C code that bridges the gap between the Java VM and existing C libraries. That C code must be compiled, and must follow some rather tedious patterns (regarding method signatures and other little details). It’s a bit of a pain to write and compile, if all you want to do is quickly call some function from an existing C library. Also, because symbol resolution is done at compile-time, this is a non starter for something like JRuby, wherein one would want to write plain Ruby code to call a C function — rather than writing Ruby, Java and JNI flavored C code. Ruby is an interpreted language, so calling into or out of C requires dynamic symbol resolution, and for the C->Ruby callback case, a closure must be created on the fly (that is, a C ABI function must be JIT compiled for that method or proc). This isn’t particular to Ruby — any interpreted language will run into this issue on the JVM (picture Python and its ctypes and/or cffi libraries). You can see some of the hoops that JRuby had to jump through to support this use case, in order to provide a JRuby implementation of the ‘ffi’ gem interface: https://javadoc.io/doc/org.jruby/jruby-core/9.2.13.0/org/jruby/ext/ffi/FFI.html https://javadoc.io/doc/org.jruby/jruby-core/9.2.13.0/org/jru... https://www.igvita.com/2009/01/15/bridging-mri-jruby-rubinius-with-ffi/ https://www.igvita.com/2009/01/15/bridging-mri-jruby-rubiniu... It’s been a minute, so my recollection may be wrong, but IIRC JRuby uses Java and JNI to call into a C shim that then calls into libffi to handle things like creating C ABI conforming closures and such on the fly (the ffi gem on CRuby also uses libffi for the same purposes). Correction: I believe JRuby uses JNA, which in turn is Java+JNI to call C that then calls into libffi, which is then leveraged to call whatever other functions (or create C callbacks back into the JVM). So I’m pretty sure FFM would be an officially supported replacement (maybe superset?) of JNA. (I’m on vacation and typed all of this out on my phone, so forgive me if I got some details a bit off) I’m pretty sure that just about all of that complexity can be ripped out once FFM is generally available.

headius 3y ago
You know a lot about JRuby's use of FFI! One correction though, JRuby uses a reimplementation of jna called jnr, which is generally much faster (close to jni for simple calls). We are working with folks on the FFM team to re-implement the core jnr back end. It's very exciting work, and I will present it this weekend at RubyConf Taiwan!