A few considerations (mostly) on jextract

[Maurizio Cimadamore]

On 14/05/2021 23:02, Markus Knetschke wrote:
> 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.
Thanks for the feedback!
>
> 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.

I hear you - this is indeed possible, at the cost of more allocation. 
For now we have tried to stick to a principle that jextract should not 
add overhead, but I tend to agree that, in the case of struct, this ends 
up being punitive at times (especially when you have structs nested 
inside structs nested inside structs).

I believe at some point some other experiment will be made to make 
struct handling more OO (as you say), and, if we can get some help from 
Valhalla primitive types, maybe we won't even pay a performance price!

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

These can be easily added - basically, you are in the situation where 
you already have a method handle, and so functional interfaces work 
_against_ you. Got it.


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

In the new API, we have a new method in MemoryLayout like this:

default MethodHandle sliceHandle(PathElement... elements) {

Which I think does what you want?

Thanks
Maurizio

>
> I'd like to provide the code for this if there is any interest in this.
>
> Best regards,
> Markus Knetschke