New candidate JEP: 412: Foreign Function & Memory API (Incubator)

[Remi Forax]

----- Mail original -----
> De: "Gerard Ziemski" <gerard.ziemski at oracle.com>
> À: "panama-dev at openjdk.java.net'" <panama-dev at openjdk.java.net>
> Cc: "Maurizio Cimadamore" <maurizio.cimadamore at oracle.com>, "jdk-dev" <jdk-dev at openjdk.java.net>
> Envoyé: Jeudi 22 Avril 2021 23:42:56
> Objet: Re: New candidate JEP: 412: Foreign Function & Memory API (Incubator)

> hi,

Hi,

> 
> I read this JEP only once so far, but one thing that I immediately noticed was
> whether MethodType is really necessary when constructing a MethodHandle, or
> whether that info can be inferred from FunctionDescriptor as in this given
> example:
> 
> 
> MethodHandle qsort = CLinker.getInstance().downcallHandle(
>        LibraryLookup.ofDefault().lookup("qsort").get(),
>        MethodType.methodType(void.class, MemoryAddress.class, long.class,
>                              long.class, MemoryAddress.class),
>        FunctionDescriptor.ofVoid(C_POINTER, C_LONG, C_LONG, C_POINTER)
> );
> 
> Seems to me that FunctionDescriptor and MethodType describe the same layout ?

MethodType is the Java signature, FunctionDescriptor is the C signature,
the CLinker is the one knowing the C convention on the actual Archiecture/OS (by example, the first two parameters are in registers, etc) so CLinker is able to expose the symbol "qsort" with the FunctionDescriptor as a method handle with the MethodType.

As noted at the end of the JEP, this is the low level API, there is a tool named jextract that provides a more high level API by generating the mapping from a C header file.

> 
> 
> cheers

regards,
Rémi

> 
>> On Apr 22, 2021, at 1:27 PM, mark.reinhold at oracle.com wrote:
>> 
>> https://openjdk.java.net/jeps/412
>> 
>>  Summary: Introduce an API by which Java programs can interoperate with
>>  code and data outside of the Java runtime. By efficiently invoking
>>  foreign functions (i.e., code outside the JVM), and by safely accessing
>>  foreign memory (i.e., memory not managed by the JVM), the API enables
>>  Java programs to call native libraries and process native data without
>>  the brittleness and danger of JNI.
>> 
> > - Mark