[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

Status: Resolved
Project: Gradle
Affects Version/s: None
Fix Version/s: 3.1-rc-1

Type: Bug
Reporter: Gradle Forums Assignee: Unassigned
Resolution: Fixed Votes: 3

Issue Links:
Related
Related to GRADLE-3467 Generated Gradle API library incompat... Resolved

 Description   

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
at com.sun.jna.Memory.malloc(Memory.java:691)
at com.sun.jna.Memory.<init>(Memory.java:90)
at com.sun.jna.ptr.ByReference.<init>(ByReference.java:33)
at com.sun.jna.platform.win32.WinReg$HKEYByReference.<init>(WinReg.java:41)
at com.sun.jna.platform.win32.WinReg$HKEYByReference.<init>(WinReg.java:37)
at com.sun.jna.platform.win32.Advapi32Util.registryGetStringValue(Advapi32Util.java:540)
at com.sun.jna.platform.win32.Advapi32Util$registryGetStringValue.call(Unknown Source)
at com.ullink.Registry.getValue(Registry.groovy:49)
at com.ullink.Registry$getValue.call(Unknown Source)
at com.ullink.Msbuild.trySetMsbuild(Msbuild.groovy:96)
at com.ullink.Msbuild$_closure1.doCall(Msbuild.groovy:40)
at com.ullink.Msbuild.<init>(Msbuild.groovy:39)
at com.ullink.Msbuild_Decorated.<init>(Unknown Source)
at org.gradle.api.internal.DependencyInjectingInstantiator.newInstance(DependencyInjectingInstantiator.java:62)
at org.gradle.api.internal.ClassGeneratorBackedInstantiator.newInstance(ClassGeneratorBackedInstantiator.java:36)
at org.gradle.api.internal.project.taskfactory.TaskFactory$1.call(TaskFactory.java:124)

(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...

Cheers

Tom

 Comments   
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...

Thanks

Tom

Comment by Denis Kuniß [ 30/Mar/15 ]

I guess, I have a similar problem only looking a little bit different.
My error on the jenkins slave is (with setting set DEFAULT_JVM_OPTS=-Djna.debug_load.jna=true at the gradle wrapper):

  Looking in C:\.gradle\native\jna\win32-amd64\jnidispatch.dll
  Trying C:\.gradle\native\jna\win32-amd64\jnidispatch.dll
  Found jnidispatch at C:\.gradle\native\jna\win32-amd64\jnidispatch.dll
  
  FAILURE: Build failed with an exception.
  
  * Where:
  Build file 'C:\Users\Public\Documents\jenkins-slave\workspace\wn-udm-p4dn\wn-udm-p4dn.gradle' line: 368  

  * What went wrong:
  A problem occurred evaluating root project 'wn-udm-p4dn'.
  > Can't obtain updateLastError method for class com.sun.jna.Native

My dependencies are 

buildscript {
	repositories { 
		mavenCentral()
	}
	dependencies { 
		classpath 'net.java.dev.jna:jna:4.1.+'
		classpath 'net.java.dev.jna:jna-platform:4.1.+'
	}
}

It seems a workaround for me was to set the wrappter JVM options as follows according to Tom's hint (Thanks Tom!):

set DEFAULT_JVM_OPTS=-Djna.boot.library.name=set_to_something_not_existing__see_issue_GRADLE-3104 -Djna.debug_load.jna=true

Would be got to have this solved by integrating the newest JNA into the Gradle distribution...

Regards, Denis

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

Generated at Wed Jun 30 12:40:04 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.