MumbleLink

MumbleLink

Mods
456k Downloads

JNA-4.0.0 dependency conflicts with JNA-3.4.0 shipped in MC 1.8.9

zsawyer opened this issue ยท 1 comments

commented

I tracked down the UnsatisfiedLinkError to be an incompatibility with Minecraft itself now.

At some point Mojang started using JNA too. But they are using an old-ass version: 3.4.0. (see %appdata%.minecraft\libraries\net\java\dev\jna\jna\3.4.0 ).

Back at MumbleLink-4.0.3 I explicitly changed to JNA-4.0.0 to stabilize library loading.

Right now, when starting Minecraft Advapi32 will be loaded using JNA-3.4.0 - since the mod is loaded last but uses the same class loader the class loader will try to load LinkAPI with JNA-3.4.0 instead of JNA-4.0.0.

The heuristics of JNA-3.4.0 are not able to locate the native library LinkAPI (e.g. LinkAPI.dll). So the mod crashes because the required library could not be loaded.

What I see are 5 options:

  1. Try using a custom class loader that uses JNA-4.0.0 while the root class loaded can stick with JNA-3.4.0 (very tricky - I have no experience with custom class loaders and am not sure if this also applies to native libraries)
  2. Somehow inject JNA-4.0.0 before the JVM even tries to load the JNA-3.4.0 - hoping that it will not break the game and load the Advapi32 using JNA-4.0.0. (this might be what is happening when you are running successfully in NetBean, but for shipping it is not very promising and seems very hacky)
  3. Downgrade MumbleLink to work with JNA-3.4.0 (maybe looking at MumbleLink-4.0.2 can give an indication on how it might work, QnD-style this might be the way to go)
  4. Upgrade MumbleLink to work with both JNA-3.4.0 and JNA-4.0.0. (not really feasible)
  5. Switch to BridJ like I was planning to do all along.

I do not believe that shading really is an option since JNA will require it's own native libraries unless they have not changed (which I do not believe) there will be conflicts of java classes expecting different native data structures then what has been loaded - JNA is really complex.

commented

Option 3 is implemented in branch QnD-MC_JNA
Option 5 is implemented in QnD but it appears to be bugged with wchar_t on Ubuntu 64 bit since it always interprets it's size as 2 bytes, even when it is 4 bytes. This seems not to be a problem with JNA.

A sixth option was to go with JNI directly again. It is really a lot of work and should really be done in the LinkAPI project.