[GRADLE-3104] Current version of JNA out of date and doesn't support various options Created: 11/Jun/14 Updated: 14/Sep/16 Resolved: 06/Sep/16
I'm trying to use the msbuild plugin. It mostly works, but for some reason when it runs in our jenkins windows slave, it falls over saying:
Caused by: java.lang.NoClassDefFoundError: Could not initialize class com.sun.jna.Native
(This is with Gradle 1.12 executed using the wrapper).
Various attempts to debug the issue using -Djna.debug=true, -Djna.debug.jna=true didn't work, as the old version of JNA included in the gradle distribution doesn't support that option.
Turns out that JNA is picking up the jnidispatch.dll included in the gradle distribution, but the plugin was attempting to load a newer version (3.5.0). The plugin has some code which attempts to work around this, but for some reason that I haven't been able to determine, when executing under jenkins it wouldn't work, and the above exception would be thrown.
My workaround in the end has been to exclude all transitive dependencies from the plugin (it pulls in the jna platform library as well), pull in jna and jna-platform 4.1.0 and then force JNA to not use the DLL in the gradle dist by setting System.properties['jna.boot.library.name'] to something nonexistent. I can't even do that in the version of JNA that gradle ships with, as that option isn't supported in 3.2.7 either.
My suggestion is to bump the version of JNA that gradle ships with to the most recent release (4.1.0). This should pick up any bugfixes that have come in since 3.2.7 which is almost 4 years old now, and that version allows workarounds like the above when necessary, should a plugin need a later version in the future.
Seems like before 2.0 would be the time to bump a dep like this, but it may be a bit late in the day...
|Comment by Gradle Forums [ 11/Jun/14 ]|
Gentle bump. Any idea if this might be looked at before 2.0? Only because it seems unlikely to get changed after that for some time...
|Comment by Denis Kuniß [ 30/Mar/15 ]|
I guess, I have a similar problem only looking a little bit different.
My dependencies are
It seems a workaround for me was to set the wrappter JVM options as follows according to Tom's hint (Thanks Tom!):
Would be got to have this solved by integrating the newest JNA into the Gradle distribution...
|Comment by Hugh Greene [ 06/Apr/16 ]|
I've voted for this issue because Gradle (at least up to 2.10) still seems to be using JNA 3.2.7, and that JNA version seems to have this bug reported against 3.2.3 – https://java.net/jira/browse/JNA-157 – the effect of which is to cause intermittent "access violations" on shutdown.
We've just started adding use of JNA to a custom plugin (to create directory junctions instead of symlnks, to avoid the need for Admin rights on Windows 8 and later) and have seen this behaviour twice in a couple of months of occasional use by only two users (the plugin developers). It's not a show-stopper since it only happens on shutdown, but it may well spook our internal users
|Comment by Sterling Greene [ 06/Sep/16 ]|
3.1 will remove the JNA library from the Gradle distribution, so plugins are free to use their own version now.
|Comment by Hugh Greene [ 14/Sep/16 ]|
Thanks, other Mr. Greene :-D