Project Panama and the future of JNA

[Daniel Widdis]

I was browsing the feature lists for JDK 16 and 17 today and noticed that JEP 389 (key parts of Project Panama) looks like it may be in JDK 16 and thus JDK 17 LTS.

 

https://openjdk.java.net/jeps/389

 

I’m curious what this means for the JNA project. Obviously JNA will still be needed in the long term to support pre-JDK 17 versions.  But a bigger meta-question:

 

For those of us who want to release a new version that supports JDK 17, should we:

• Port our code directly to the new JEP 389 code, or
• Is there a way to change JNA’s linking/FFI under the hood in a new release targeting JDK17, to continue to use our existing JNA dependencies but gain the same benefits?

[Daniel D.]

Having read that proposal it seems like it's quite far off being able to declare a function interface that directly matches the native interface, and instead one will have to do some pretty serious code gymnastics to invoke a native function, albeit better than writing a native JNI binding. Which is great, but as a developer I just never want to do that.

I think JEP 389 can theoretically replace all the native portions of JNA, and we will want to preserve all the high level interfaces. Or another library ala JNA will want to wrap the code gymnastics to provide complete definitions of native SDKs.   

--
You received this message because you are subscribed to the Google Groups "Java Native Access" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jna-users+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jna-users/6AA37A7F-3A3F-4E05-92C1-F1CAF8A31672%40gmail.com.

--

dB. | Moscow - Geneva - Seattle - New York
code.dblock.org - t:@dblockdotorg - ig:@artdblockdotorg - github/dblock

[Neil C Smith]

On Thu, 17 Dec 2020 at 14:07, Daniel D. <dbl...@dblock.org> wrote:
> Having read that proposal it seems like it's quite far off being able to declare a function interface that directly matches the native interface, and instead one will have to do some pretty serious code gymnastics to invoke a native function,

You need to also look at the jextract tool. eg.
https://inside.java/2020/10/06/jextract/

There may still be things a next-gen JNA might add to that? But I
think if JNA was rewritten on it you'd want to keep access to the
underlying API.

There might not be a huge rush - it'll be interesting to see if this
gets out of incubation by Java 17. Preview features and LTS - lovely
mix! :-)

Best wishes,

Neil



--
Neil C Smith
Codelerity Ltd.
www.codelerity.com

Codelerity Ltd. is a company registered in England and Wales
Registered company number : 12063669
Registered office address : Office 4 219 Kensington High Street,
Kensington, London, England, W8 6BD