panama-foreign VS jextract

Going to copy my Reddit comment over to HN because I think it's valuable:

---

One of the coolest things that's been worked on (by this same author, no less!) isn't even in the article!

Per has written a pretty-printer for MemorySegments and ByteBuffers that can hex-dump memory or render memory/buffers as their "struct" representations given some MemoryLayout.

You can also customize it with your own printers, it's wicked cool and helps so much to debug buffers when working with them.

https://github.com/openjdk/panama-foreign/pull/695

What do I mean by that? Have a look at this comment for an image of a raw memory structure layout I represented with MemoryLayout, and the pretty-print rendering of it:

https://github.com/openjdk/panama-foreign/pull/695#issuecomm...

[Here's the project github](https://github.com/openjdk/panama-foreign)

I am not using any special flag (is there one?) but the overhead seems quite high, especially considering the explanation on how these methods are compiled https://github.com/openjdk/panama-foreign/blob/foreign-jextract/doc/panama_ffi.md

https://github.com/openjdk/panama-foreign/blob/foreign-jextract/doc/panama_jextract.md ..look at these examples

I found the full context for the change written up here https://github.com/openjdk/panama-foreign/pull/554

Incentive for JVM devs? We know that C interoperability, malloc, free, structs are already supported on JVM natively since Java 14 with project panama's foreign-memory-api without JNI. I've been using sun.misc.Unsafe since Java8 and also LWJGL's C API.

ok, maybe I mixed it up with jextract https://github.com/openjdk/jextract

This is one level below P/Invoke. It just offers a linking runtime API.

There's also has a tool that can generate all the bindings from a C header file automatically: https://github.com/openjdk/jextract

Then it doesn't really matter whether annotations are used or not, or some more low-level linker API (like FFM went with). As a user you just call into the generated bindings.

That's the philosophy: the JDK provides the low-level capabilities, and jextract provides the 'civilization', i.e. a usability focused layer on top. One of the advantages is that the JDK doesn't compete with other existing solutions, and those existing solution can benefit from the new linking runtime APIs as well.

Depending on how work-aroundy you're feeling, using Kotlin/JVM with Panama and jextract might be the way to go. The generated bindings are a bit ugly, you'd need to use the very latest JVM and enable the preview features, and it won't help if you need to target iOS. But the jextract tool can fully understand C headers including macros because it's using the LLVM clang API to do so.

You can use jextract and a JDK 19 pre-release build to generate bindings and then do a JMH benchmark.

None of that needs to be done in the JDK, though, and the "big" project that can make a big difference here is jextract. The rest can easily be done by libraries.

Panama incubator module is available on jdk 17 and you can also use jextract (https://github.com/openjdk/jextract) to generate all java code without writing any JNI glue code.