[adra]

I started to tinker with this new API last week. I definitely think it's a lot better than needing to self compile a lot of the bindings yourself which will certainly bring more from the community into the feature than were here before.

That said, you really need to write a bunch of boiler-plate to implement useful things in java-like paradigms in the library today. Just as an example, I wrote up a sane windows _getcwd() stub and it's like 30 lines to implement correctly (properly freeing the buffer when I'm down with it)

My pet project is to see if I can write automatic stubs around calls based on published API info and sources, so that at least some of that platform binding lift isn't just for those with non-trivial knowledge of C. Well, that's the hope anyways.

[schoenobates]

I've been quite keen on the new FFI too - apologies if this is old news, but have you tried the [0] jextract stuff for some of the boilerplate gubbins?

[0]: https://github.com/openjdk/jextract

[adra]

No! Thanks for the callout! That would certainly help on my path. My main goal was to insulate calls to avoid overly complicated reference counting when integrating large native surfaces into as Java program, but certainly an important aspect is getting the function signatures to target in the first place. I threw something bad together to work sort of like this (testing using proton), but I'm more than happy to bin it for something that just-works.

[ptx]

Have you looked at Microsoft's Win32 API metadata package [0]? They're using it to generate C# and Rust bindings, and other people have targeted other languages.

[0] https://github.com/microsoft/win32metadata