Shade/Relocation support

[jikuja]

I tried HelloWorld example from Getting Started Guide and got following results:

Result of shadowjar, no relocation. Works as excepted:

jikuja@LG MINGW64 /d/projects/jna-relocation-bug
$ java -Djna.debug_load.jna=true -jar build/libs/jna-relocation-bug-1.0-SNAPSHOT-all.jar
Trying (via loadLibrary) jnidispatch
Looking in classpath from sun.misc.Launcher$AppClassLoader@4e25154f for /com/sun/jna/win32-x86-64/jnidispatch.dll
Found library resource at jar:file:/D:/projects/jna-relocation-bug/build/libs/jna-relocation-bug-1.0-SNAPSHOT-all.jar!/com/sun/jna/win32-x86-64/jnidispatch.dll
Trying C:\Users\jikuja\AppData\Local\Temp\jna--1160004128\jna5363526492694878451.dll
Found jnidispatch at C:\Users\jikuja\AppData\Local\Temp\jna--1160004128\jna5363526492694878451.dll
Hello, World

Shadowjar with relocation. Does not work:

jikuja@LG MINGW64 /d/projects/jna-relocation-bug
$ java -Djna.debug_load.jna=true -jar build/libs/jna-relocation-bug-1.0-SNAPSHOT-reloc.jar
Trying (via loadLibrary) jnidispatch
Looking in classpath from sun.misc.Launcher$AppClassLoader@4e25154f for /a/com/sun/jna/win32-x86-64/jnidispatch.dll
Found library resource at jar:file:/D:/projects/jna-relocation-bug/build/libs/jna-relocation-bug-1.0-SNAPSHOT-reloc.jar!/a/com/sun/jna/win32-x86-64/jnidispatch.dll
Trying C:\Users\jikuja\AppData\Local\Temp\jna--1160004128\jna2069879652875333160.dll
Found jnidispatch at C:\Users\jikuja\AppData\Local\Temp\jna--1160004128\jna2069879652875333160.dll
Exception in thread "main" java.lang.UnsatisfiedLinkError: a.com.sun.jna.Native.sizeof(I)I
        at a.com.sun.jna.Native.sizeof(Native Method)
        at a.com.sun.jna.Native.<clinit>(Native.java:141)
        at HelloWorld$CLibrary.<clinit>(HelloWorld.java:13)
        at HelloWorld.main(HelloWorld.java:20)

Build script I used: https://gist.github.com/jikuja/10e29922c819e2a0eb16183a09a14f38

Bug or did I miss some important configuration flag to enable proper shading support?

[twall]

What's happening is that JNI is expecting to find a native method based on
the package and class name of the containing Java class. You've
effectively renamed the package/class, so JNI's "guess" of the native
symbol is now not going to match.

JNA uses JNI's default symbol mapping to find native functions (such as
Native.sizeof). You'd have to either avoid "relocating" those specific
functions (and running the full suite of JNA tests to ensure you didn't
break something else) or rewriting JNA's code which references native
functions to do a different type of lookup of native methods (it's possible
to take a Java method and explicitly bind it to an explicit native symbol,
but it's not clear that would generally be a good thing for JNA to do, even
if it makes your life easier in this specific case).

On Tue, Jul 12, 2016 at 12:05 PM, jikuja notifications@github.com wrote:

I tried HelloWorld example from Getting Started Guide and got following
results:

Result of shadowjar, no relocation. Works as excepted:

jikuja@LG MINGW64 /d/projects/jna-relocation-bug
$ java -Djna.debug_load.jna=true -jar build/libs/jna-relocation-bug-1.0-SNAPSHOT-all.jar
Trying (via loadLibrary) jnidispatch
Looking in classpath from sun.misc.Launcher$AppClassLoader@4e25154f for /com/sun/jna/win32-x86-64/jnidispatch.dll
Found library resource at jar:file:/D:/projects/jna-relocation-bug/build/libs/jna-relocation-bug-1.0-SNAPSHOT-all.jar!/com/sun/jna/win32-x86-64/jnidispatch.dll
Trying C:\Users\jikuja\AppData\Local\Temp\jna--1160004128\jna5363526492694878451.dll
Found jnidispatch at C:\Users\jikuja\AppData\Local\Temp\jna--1160004128\jna5363526492694878451.dll
Hello, World

Shadowjar with relocation. Does not work:

jikuja@LG MINGW64 /d/projects/jna-relocation-bug
$ java -Djna.debug_load.jna=true -jar build/libs/jna-relocation-bug-1.0-SNAPSHOT-reloc.jar
Trying (via loadLibrary) jnidispatch
Looking in classpath from sun.misc.Launcher$AppClassLoader@4e25154f for /a/com/sun/jna/win32-x86-64/jnidispatch.dll
Found library resource at jar:file:/D:/projects/jna-relocation-bug/build/libs/jna-relocation-bug-1.0-SNAPSHOT-reloc.jar!/a/com/sun/jna/win32-x86-64/jnidispatch.dll
Trying C:\Users\jikuja\AppData\Local\Temp\jna--1160004128\jna2069879652875333160.dll
Found jnidispatch at C:\Users\jikuja\AppData\Local\Temp\jna--1160004128\jna2069879652875333160.dll
Exception in thread "main" java.lang.UnsatisfiedLinkError: a.com.sun.jna.Native.sizeof(I)I
at a.com.sun.jna.Native.sizeof(Native Method)
at a.com.sun.jna.Native.(Native.java:141)
at HelloWorld$CLibrary.(HelloWorld.java:13)
at HelloWorld.main(HelloWorld.java:20)

Build script I used:
https://gist.github.com/jikuja/10e29922c819e2a0eb16183a09a14f38

Bug or did I miss some important configuration flag to enable proper
shading support?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#679, or mute the thread
https://github.com/notifications/unsubscribe/AAuMreuVk9jXz02KY5eUnENLNETqKhe3ks5qU7tjgaJpZM4JKjTX
.

[PumpkinXD]

so, any ways to get around it?

I'm backporting a minecraft mod from mc1.12.2 to mc1.8.9

I want to use a newer version of jna(for extract feature) but jna3.4 is used in mc1.8.9 which don't have such feature and causing this issue

[facewindu]

Is there a definitive answer here ? Like "no, JNA will never support this feature" ?
I'm developing a java application which embeds a library (called LIB) that uses JNA.
If, for some reasons I can't control, there is another version of JNA (say B) on the classpath (e.g. the user of my application has the need for JNA and declared a JNA dependency that is different from my JNA dependency version (say A)), then we might run into a problem because JNA B might already be loaded and will be used, and might not contain the native methods called on JNA A via my embedded LIB.

One way out of that is to shade/relocate JNA in my application (as well as my LIB) to, say, com.acme.com.sun.jna.xxx.
The JNA dispatch lib is properly found, as seen above, and is loaded.
But then JNA chokes on native calls (in my case com.acme.com.sun.jna.Native#getNativeVersion(), which is private static native String getNativeVersion()) because the dispatch lib has it declared as Java_com_sun_jna_Native_getNativeVersion.

Is there any other way, as a consumer of JNA, that would allow two JNA versions to coexist in a classpath, other than shading/relocating?
Because the described use case (a java application which embeds a library that uses JNA) seems legit to me.

It seems to me that we can work around the second aspect of this problem (i.e. native calls to other libraries loaded via JNA), thanks to function mapping, that would map from a relocated com.sun.jna.Library subclass methods to the original (non relocated) native lib methods.

[Zacgamingpro1234]

Any solutions or alternatives? I'm having this issue in my minecraft 1.8.9 mod....