3 ms·

I am sort of surprised that there isn't a widely used tool that uses codegen to generate jni bindings sort of like what the jna does but at build time. You coul

I am sort of surprised that there isn't a widely used tool that uses codegen to generate jni bindings sort of like what the jna does but at build time. You could go meta and bundle a builder in a jar that looks for the shared library in a particular place and shells out to build and install the native library if it is missing on the host computer. This would run once pretty similar I think to bundling native code in npm. I have bundled shared libraries for five or six platforms in a java library that needs to make syscalls. It works but it is a pain if anything ever changes or a new platform needs to be brought up. Checking in binaries always feels icky but is necessary if not all targets can be built on a single machine. The problem with the new api is that people upgrade java very slowly in most contexts. For an oss library developer, I see very little value add in this feature because I'm still stuck for all of my users who are using an older version of java. If I integrate the new ffi api, now I have to support both it and the jni api.

MaxBarraclough 2y ago
> I am sort of surprised that there isn't a widely used tool that uses codegen to generate jni bindings sort of like what the jna does but at build time There are several, including SWIG.
- andoando 2y ago
  Which is still a pita to use unless maybe you really know what youre doing.
  - TillE 2y ago
    Binding generation is really difficult to approach as a general problem, which is why I've found that SWIG unfortunately doesn't help much in non-trivial cases. All the good bindings I use are generated by custom systems (ie, usually some Python scripts) tailored for the specific way their library works.
lelanthran 2y ago
There is SWIG, which does bings to and from C for almost every language that exists.
PaulHoule 2y ago
Back in 1998 I wrote a code generator to make JNI stubs for LAPACK. It’s the kind of programming that goes that way.
gudzpoz 2y ago
There is a library called jnigen [1], mainly used by the libGDX framework [2]. But I don't see it used in many other projects though. Personally I use it to maintain a set of Lua C API bindings for some platforms [3] and it works sort of OK once you manage to somehow set up a workflow for building and testing the binaries. > It works but it is a pain if anything ever changes or a new platform needs to be brought up. Checking in binaries always feels icky but is necessary if not all targets can be built on a single machine. It is definitely a pain when you cannot test all changes on a single local machine. But I would argue that it is true whenever multiple platforms (or maybe even multiple glibc versions) are involved, regardless of what languages/libraries/tools you use. [1] https://libgdx.com/wiki/utils/jnigen https://libgdx.com/wiki/utils/jnigen [2] https://github.com/libgdx/libgdx https://github.com/libgdx/libgdx [3] https://github.com/gudzpoz/luajava https://github.com/gudzpoz/luajava

MaxBarraclough 2y ago

> I am sort of surprised that there isn't a widely used tool that uses codegen to generate jni bindings sort of like what the jna does but at build time There are several, including SWIG.

andoando 2y ago
Which is still a pita to use unless maybe you really know what youre doing.
- TillE 2y ago
  Binding generation is really difficult to approach as a general problem, which is why I've found that SWIG unfortunately doesn't help much in non-trivial cases. All the good bindings I use are generated by custom systems (ie, usually some Python scripts) tailored for the specific way their library works.

lelanthran 2y ago

There is SWIG, which does bings to and from C for almost every language that exists.

PaulHoule 2y ago

Back in 1998 I wrote a code generator to make JNI stubs for LAPACK. It’s the kind of programming that goes that way.

gudzpoz 2y ago

There is a library called jnigen [1], mainly used by the libGDX framework [2]. But I don't see it used in many other projects though. Personally I use it to maintain a set of Lua C API bindings for some platforms [3] and it works sort of OK once you manage to somehow set up a workflow for building and testing the binaries. > It works but it is a pain if anything ever changes or a new platform needs to be brought up. Checking in binaries always feels icky but is necessary if not all targets can be built on a single machine. It is definitely a pain when you cannot test all changes on a single local machine. But I would argue that it is true whenever multiple platforms (or maybe even multiple glibc versions) are involved, regardless of what languages/libraries/tools you use. [1] https://libgdx.com/wiki/utils/jnigen https://libgdx.com/wiki/utils/jnigen [2] https://github.com/libgdx/libgdx https://github.com/libgdx/libgdx [3] https://github.com/gudzpoz/luajava https://github.com/gudzpoz/luajava