Relocation support

[François Guillot]

Hi,

I'm asking to discuss the status of https://github.com/java-native-access/jna/issues/679.

I understand that there are reasons to not support that natively in JNA, but then I do wonder what the alternatives are.

As stated in the issue, I think the following is a very valid use case:

- I'm developing a java application which embeds a library (called LIB) that uses JNA (say version A). I don't control the development of LIB.

- For some reasons, another version of JNA (version B) is on the classpath. Maybe because the user of my application is also using another library that depends on JNA.

JNA B (or JNA A) might be loaded first and make the other library not work (because of some JNA signature changes, for instance)

The typical solution for this kind of problem is to shade and relocate your runtime dependencies, so that they don't collision with others.

But this is not working with JNA, because the relocated `com.sun.jna.Native class` (say to `relocated.com.sun.jna.Native`) cannot use its own `jnidispatchlib` native calls, that are expecting method signatures to match the original `com.sun.jna.Native` FQCN.

Function mapping allows to treat libraries loaded via JNA independently of where their Java counterparts live, but that's not working for jnidispatch.

Did I understand it correctly ?

Are there some other options to ensure two versions of JNA can coexist ?

(I was thinking to use a child-first classloader in my application, for the threads that interact with JNA, so that it can load a new instance of the (non-relocated then) Native class, which would hold its own state and have its own handle to its own jnidispatch lib, but I'm sure this could lead to weird problems.

If no other options exist, don't you think this is a valid case ?

many thanks for your insights,

François

[Kustaa Nyholm]

IMO embedding and distributing JRE with the application is pretty much the only sane way today, JNA or not, so the question becomes moot?

CONFIDENTIALITY NOTICE: The contents of this email message, and any attachments, are intended solely for the addressee(s) and may contain confidential, proprietary and/or privileged information legally protected from disclosure. If you are not the intended recipient of this communication, or if you received this communication by mistake, please notify the sender immediately and delete this message and any attachments. If you are not the intended recipient, you are hereby notified that any use, retransmission, dissemination, copying or storage of this message or its attachments is strictly prohibited.
--
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 visit https://groups.google.com/d/msgid/jna-users/e7a2c920-3e3c-4d8b-852a-92d2f30c1f02n%40googlegroups.com.

[Tres Finocchiaro]

IMO embedding and distributing JRE with the application is pretty much the only sane way today, JNA or not, so the question becomes moot?

From what I can tell, the OP is asking about running multiple simultaneous copies of JNA, which bundling the Java runtime does not necessarily fix.

See "The Bad" and "The Ugly" here:

https://softwareengineering.stackexchange.com/a/351091/356971

(Sorry I don't have an answer to the original question.  In my case, instead of shading, I generally use a bundling/clobbering technique with the latest and hope the API doesn't change in a way that breaks both implementations however this is NOT what's being asked, so I didn't want to offer it as solution to a valid shading question).

 

- Tres.Fin...@gmail.com