Clojurians Log v2

This link that graalvm posted today seems to indicate that JNA has been community tested, https://www.graalvm.org/native-image/libraries-and-frameworks/. I haven't JNA myself, but it would be great if it worked out the box with native-image.

@smith.adriane Interesting! Worth a demo project I'd say https://github.com/oracle/graalvm-reachability-metadata/blob/master/metadata/net.java.dev.jna/jna/5.8.0/jni-config.json

@smith.adriane Would you consider JNA to be more dynamic, e.g. suited to be used in bb scripts for example?

I think so. I think you could do most ffi calls at runtime as long as JNA is supported. I'm not sure you could make ffi calls with struct args or return values though.

The best fit might still be a custom libffi wrapper so that bb scripts could support structs by value. You might also be able to better control how it affects binary size.

There might also be a way to package runtime support for structs by value with JNA (since JNA uses libffi under the hood and libffi does support runtime structs by value)

ah

using libffi directly might be interesting. the last POC you did added quite some size to bb though

right, but in theory, you could strip other packaged libs out of bb and offer them a la carte via ffi for an overall smaller bb.

wasn't there also a restriction of not being able to pass functions over the FFI border?

oh, right. you would be restricted to passing values that can be serialized

similar to pods

I was wondering why libffi added so much to the size of the binary. Looking at my code, I just realized that it might be because I'm pulling in dtype next to make the ffi calls. I wonder if it would make a difference if I generated the ffi calls using https://github.com/phronmophobic/clong.

clong let's you do the generation ahead of time and doesn't need to be included at runtime.

interesting

That's really cool, my last attempt at using JNA in a native image was a disaster