What are the impacts of Panama on JNA?

[Davide Perini]

Hi there,
will Panama have some impacts on JNA?

I don't know JNA but as far as I understood JNA uses JNI,
will this change with Panama?

What is the best approach to call a Windows Native API this days?
To create a toast for example.

Should I add something to JNA or should I follow the panama route?

I'm sorry for the noob questions :)

Davide

[Support]

Hi Davide,

a few weeks ago I stood at the same starting point and I chose JNA.

Panama and FFI are not ready and/or properly digested yet. Simply not enough references outside, no-one to ask, no samples to copy'n paste.

JNA may be slower but is pretty simple to use with good documentation and examples around. In my opinion, still the way to go for the next 3-5 years -- unless you have a large number of high frequency Native Calls.

Cheers

Andreas

[Scott Palmer]

I’m of the opposite opinion. These days Panama should be the first choice and JNA for when Panama doesn’t fit. Like if you have to run on an older JRE. Lack of examples is a poor reason not to choose Panama, unless for some reason you can’t make it work after reading the docs. I have nothing against JNA and have used it happily, but we mostly don’t need it anymore, and that’s a good thing. 

Scott

On Jan 9, 2024, at 6:49 AM, Support <sup...@manticore-projects.com> wrote:



--
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/3277fa76be1c4c9f8b6af1f72a45f1d097a6dd9a.camel%40manticore-projects.com.

[Chris Nuernberger]

I have a few pretty major pieces of software running on top of JNA, Panama's FFI, or Graal Native the most popular being libpython-clj.  Panama is faster for granular calls but it specifically uses the very poorly designed java load-library pathway to find shared libraries as opposed to say - system path.  Thus it fails to find common system libraries especially in dockerized environments or really any ubuntu distro or you name it.  Furthermore it plays some odd tricks with the system shared library loader so for something like python which has a plugin system you can have a situation where you load the main shared library (libpython.so) and when the main library attempts to load a binary plugin that needs symbols from the main library that plugin fails to find symbols in the parent executable - something that succeeds just fine with JNA.

We haven't seen a realistic situation where the speed benefits of panama make a difference from a carefully designed JNA system so it seems to me that staying with JNA just means less fuss in the long run.  So my opinion is JNA just leads to fewer overall problems with distribution and 'just works' in a larger number of corner cases - things which can be very painful to debug if you have to debug them.  Avoid highly granular calls between languages in the architectural phase to limit that risk.

Chris

To view this discussion on the web visit https://groups.google.com/d/msgid/jna-users/184955DA-35AB-49FF-AA73-4501C115EA78%40gmail.com.

[Tres Finocchiaro]

I use JNA for platform-specific reasons (Desktop application) for doing tasks such as native UI calls to Windows, Mac or Linux on Intel, ARM and RISC-V platforms.

Out of the box, JNA comes with several "contrib" utilities which can be used directly or used as boilerplate code to interact with many OS components.  Furthermore, the JNA developers have answered many commonly asked questions on mailing lists like this and online forums such as stackoverflow which lower the barrier to entry.  Finally, if you crawl GitHub projects, there is a heavy use of JNA, so as a casual JNA user, it will take some time to switch away and even when I do, many of the boilerplate "contrib" utilities will need to be replicated in whole or in part and it's a bit uncertain as to where these projects will live (I assume in separate GitHub projects, gists and forums).

There have been some attempts to write wrappers, such as this project: https://github.com/FalsePattern/jwin32 but in the case of jwin32, no precompiled binaries exist, so it will still have a higher barrier to entry for basic native tasks.

At time of writing this, performance is not a large concern of mine personally.... This is because most of the OS API calls that I need today are small and the data exchanged is also small.  Furthemore, as Andreas has mentioned, the community support for Panama is a bit early to have a knowledge base of questions and answers available.

I also help with some other projects that build C++ code and use JNA or JNI to interact.  For those projects, I believe Panama will be better suited for simplicity and performance reasons, but will require raising the JDK level.  Since JDK17 (LTS) is supported until 2026, switching an older project that uses C++ bindings to JDK21 (LTS) will likely occur on or after that time (if at all).

[Daniel Widdis]

I did some experimentation and initial implementation when JDK 19 first came out and posted here (I haven't looked at it much since then.).  That thread is here:

https://groups.google.com/g/jna-users/c/xnbkfLFraWY/m/q-8-D2GrBQAJ

The TLDR from my perspective:

 - JNA's abstraction of structures are a lot easier to work with for most normal cases

 - JEP424 code is faster

As the maintainer of a JNA-based project that needs to support JDK's prior to 21, I'm still using JNA.  Sometime in the next year or two or three, I'll probably figure out a way to create a separate artifact that uses JEP424 code for "hot path" implementations where they have the most value.  Off the hot-path, I think the ease of use of JNA is preferable.

At some point in the very distant future, when nobody is using Java versions older than 21, maybe this will change, but I have a feeling I'll be spending more time patching Y2038 bugs than messing with this by that time.

[Markus Karg]

Panama is definitively here to stay, and it is already faster than JNA, and it implicitly gains full support of all Java distributors. OTOH JNA might be easier to use (this is questionable) and comes with lots of existing API wrappers (which is great). So IMHO the future of JNA lies in its API side, while its backend core could be replaced by Panama. That would combine the best of both worlds: Keeping the simplicity of the JNA API and the existing set of API wrappers, but gain the platform-independence and speed of Panama. Whether that is actually feasible is questionable, actually. IMHO it might be easier to rewrite the existing API wrappers directly on Panama, and drop the (possibly easier) JNA API.

(Disclaimer: I am an OpenJDK contributor, so my views might be biased)

[Chris Nuernberger]

The question isn't whether it exists nor whether it is faster.  It is markedly less robust in a couple dimensions as I mentioned.  The [ffi system](https://cnuernber.github.io/dtype-next/tech.v3.datatype.ffi.html) we use produces bindings for jNA, graal native, and Panama so we have tested this rather extensively.  Note my specific concerns and issues w/r/t running things like libpython and attempting to use numpy.  For one off independent shared libraries it may work fine although you have to rebuild the OS facilities regarding the PATH as java.library.path is poorly constructed but for things that are more involved we hit barriers we could not get past.

--

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/cd8baafd-fe34-4f11-ad40-3968f4f2d47cn%40googlegroups.com.

[Markus Karg]

Have you told the OpenJDK team about those unpassable barriers?

[Daniel D.]

> So IMHO the future of JNA lies in its API side, while its backend core could be replaced by Panama.

This resonates with me. In the end what matters is "what do users (developers) want to write to call a native function", and JNA is the absolutely simplest interface that matches 100% a native interface on any platform, all while taking care of avoiding pitfalls such as mapping structures or passing strings in/out. Everything else becomes an implementation detail for the library maintainers. 

To view this discussion on the web visit https://groups.google.com/d/msgid/jna-users/c21e2960-fa14-43b0-b162-571963c50bd6n%40googlegroups.com.

--

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