A few considerations (mostly) on jextract

[Markus Knetschke]

Hello,

I currently experimenting with the foreign linker and jextract. A few
tests showed very good performance and nice usability. I've yet to
come to a c header which resulted in broken generated classes.
Something I've seen often with other tools for jna / jnr. It's a nice
replacement for jni.

But there some inconveniences using jextract I've encountered:

1) the classes for structs jextract generates don't feel very oo to
me. I would like to see a class with constructor and getter/setter
methods encapsulating the MemorySegment.
2) there is no public interface to get the FunctionDescriptor and the
MethodType of callbacks. (ok the MethodType could get extracted by
Reflection from the generated interface) If you start with a
MethodHandle already you have to either wrap it with
MethodHandleProxies.asInterfaceInstance or writing the already
existing information into your written code. I would like to see a
getter for the MethodType and a method registering a method handle as
a callback (something like static MemorySegment allocate(MethodHandle
mh)) or two getters for MethodType and FunctionDescriptor.
3) I often encounter fixed-length arrays in structs holding stings.
The best way I've found to extract them safely is to first get the
start offset of the string with MemoryLayout.byteOffset(path) then
extracting the size of the struct field with
MemoryLayout.select(path).byteSize() and reading the string with
CLinker.toJavaString(struct.asSlice(offset, size)) this is very bulky
for simple things like putting ten strings from a struct into a
record. I would like to see a simpler way for this for example a
MemorySegment.asSlice(MemoryLayout, PathElement...) method. (This
would be handy too for byte array struct fields.

I'd like to provide the code for this if there is any interest in this.

Best regards,
Markus Knetschke