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

Remi Forax forax at
Thu Apr 22 22:54:32 UTC 2021

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

> 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


>> On Apr 22, 2021, at 1:27 PM, mark.reinhold at wrote:
>>  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

More information about the jdk-dev mailing list