Comment by thefaux | Hacker News Reader

Comment by thefaux | Hacker News Reader

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.

> 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.

Which is still a pita to use unless maybe you really know what youre doing.

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.

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

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

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 [2] https://github.com/libgdx/libgdx [3] https://github.com/gudzpoz/luajava

Reply on news.ycombinator.com