4 ms·

Is FFM intended to be a full replacement? I am kind of curious what the differences are in greater detail. A previous place I worked built an entire library mos

Is FFM intended to be a full replacement? I am kind of curious what the differences are in greater detail. A previous place I worked built an entire library mostly around calling C lib from a Java interface.

pjmlp 3y ago
In the JVM, long term, yes. On Java based platforms like Android, most likely never. At least since ART became APEX compliant, Java 11 and 17 LTS are now available.
grishka 3y ago
The main difference is that for JNI, you need a library that exports specifically Java-callable functions with signatures like void Java_org_package_name_ClassName_method(JNIEnv *env, jobject _this, ...) These are bound to `native` methods in classes when you load the library with `System.loadLibrary()`. Most often these libraries are thin wrappers that call into a C/C++/Rust library and convert data between Java and C representations (especially arrays and strings). It's tedious, it's annoying, and it's a platform-dependent artifact you need to ship with your app and build for all platforms on which your app runs. FFM, on the other hand, is a proper foreign function interface. You don't need any wrappers with it, you'd just load your native library of interest directly and obtain method handles to call its C functions.
- marwis 3y ago
  On the other hand C/C++ APIs only truly exist in textual format. Without going through C you don't have access to type definitions (you have to redeclare them in Java) or macros (sometimes not even impossible). Structure layout might be different across platforms/versions/variants, symbols can be aliased through preprocessor etc. even though end API is the same. This is a problem with any FFI that tries to avoid C. Look at this mess of trying to do POSIX in JNR: https://github.com/jnr/jnr-posix/tree/master/src/main/java/jnr/posix https://github.com/jnr/jnr-posix/tree/master/src/main/java/j... - each system needs different implementation and within them there is further branching based on versions. There is no guarantee that any of this will work in the future (except on Windows which maintains stable userland ABI).
  - mike_hearn 3y ago
    Panama FFI has a tool called jextract that parses C headers and writes the Java bindings for you.
    - marwis 3y ago
      But can it generate bindings for multiple abi variants? This would seem extremely complicated to automate.
      - mike_hearn 3y ago
        It can understand preprocessor macros, and the FFI's CLinker class understands different platform ABIs. So I guess you could generate several different packages with variant ABIs, abstract over them and then use whichever one seems to be available.
        marwis 3y ago
        Abstract over them meaning writing wrappers by hand?
      - grishka 3y ago
        The ABI stuff is taken care of at runtime.
        marwis 3y ago
        What do you mean?
        grishka 3y ago
        You only specify the function signatures and structs. The JVM then figures out how to put arguments and return values into registers/stack/whatever at runtime, depending on which OS and CPU it's running on. That's what the `CLinker` class is responsible for. It's like regular dynamic linking, but taken a bit further.

pjmlp 3y ago

In the JVM, long term, yes. On Java based platforms like Android, most likely never. At least since ART became APEX compliant, Java 11 and 17 LTS are now available.

grishka 3y ago

The main difference is that for JNI, you need a library that exports specifically Java-callable functions with signatures like void Java_org_package_name_ClassName_method(JNIEnv *env, jobject _this, ...) These are bound to `native` methods in classes when you load the library with `System.loadLibrary()`. Most often these libraries are thin wrappers that call into a C/C++/Rust library and convert data between Java and C representations (especially arrays and strings). It's tedious, it's annoying, and it's a platform-dependent artifact you need to ship with your app and build for all platforms on which your app runs. FFM, on the other hand, is a proper foreign function interface. You don't need any wrappers with it, you'd just load your native library of interest directly and obtain method handles to call its C functions.

marwis 3y ago
On the other hand C/C++ APIs only truly exist in textual format. Without going through C you don't have access to type definitions (you have to redeclare them in Java) or macros (sometimes not even impossible). Structure layout might be different across platforms/versions/variants, symbols can be aliased through preprocessor etc. even though end API is the same. This is a problem with any FFI that tries to avoid C. Look at this mess of trying to do POSIX in JNR: https://github.com/jnr/jnr-posix/tree/master/src/main/java/jnr/posix https://github.com/jnr/jnr-posix/tree/master/src/main/java/j... - each system needs different implementation and within them there is further branching based on versions. There is no guarantee that any of this will work in the future (except on Windows which maintains stable userland ABI).
- mike_hearn 3y ago
  Panama FFI has a tool called jextract that parses C headers and writes the Java bindings for you.
  - marwis 3y ago
    But can it generate bindings for multiple abi variants? This would seem extremely complicated to automate.
    - mike_hearn 3y ago
      It can understand preprocessor macros, and the FFI's CLinker class understands different platform ABIs. So I guess you could generate several different packages with variant ABIs, abstract over them and then use whichever one seems to be available.
      - marwis 3y ago
        Abstract over them meaning writing wrappers by hand?
    - grishka 3y ago
      The ABI stuff is taken care of at runtime.
      - marwis 3y ago
        What do you mean?
        grishka 3y ago
        You only specify the function signatures and structs. The JVM then figures out how to put arguments and return values into registers/stack/whatever at runtime, depending on which OS and CPU it's running on. That's what the `CLinker` class is responsible for. It's like regular dynamic linking, but taken a bit further.