[GRADLE-3029] Jdk6JavaCompiler.findCompiler() causes concurrency issues by setting "java.home" system property Created: 18/Feb/14  Updated: 10/Dec/15  Resolved: 10/Dec/15

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

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

Attachments: Text File gradle3029.txt    


Jdk6JavaCompiler.findCompiler() causes concurrency issues by setting "java.home" system property for resolving Java Compiler.
We started to try to run with --parallel yesterday and in our case this causes the following exception when resolving dependency (sporadically, of course, i.e. around 2 times out of 50):

Caused by: java.io.FileNotFoundException: C:\devtools\jdk1.7.0_45_x64\lib\security\cacerts (The system cannot find the path specified)
at org.apache.http.conn.ssl.SSLSocketFactory.createSystemSSLContext(SSLSocketFactory.java:299)
at org.apache.http.conn.ssl.SSLSocketFactory.createSystemSSLContext(SSLSocketFactory.java:366)
... 95 more

httpclient expects cacert to be in System.getProperty("java.home")/lib/security/cacert, but "java.home" is set to JDK-dir temporarily by the method mentioned above.

By default, on Oracle JDK, "java.home" is always set to /jre if there is such a directory, even if started with JAVA_HOME= and/or with /bin/java. That means: usually it does find the cacert in the jre/lib folder fine, but if the "findCompiler" method changes "java.home" in that moment, it fails.

I am running on Windows 2012 Server with gradle 1.9, but I saw the source is the same in 1.11.

ToolProvider.getSystemJavaCompiler(), which is used there, will find the tools.jar correctly without all that logic, at least on windows.
This might be different on other OSses, especially with macos, which has (or had?) a different folder structure.
[1] http://forums.gradle.org/gradle/topics/unable_to_find_a_javac_compiler_under_mac_os_with_java_1_7_gradle_1_1

Comment by Gradle Forums [ 18/Feb/14 ]

Our workaround for now is to set javax.net.ssl.trustStore explicitely to `<JDK_HOME>/jre/lib/security/cacert` and provide javax.net.ssl.trustStorePassword with the default password for cacert.
We really want to go with parallel because it speeds up the build a lot. Lets see what we run into next

Comment by Sebastian Glahn [ 20/Nov/14 ]

Looks like I also run into this issue: http://forums.gradle.org/gradle/topics/filenotfoundexception-jdk-lib-security-cacerts

Comment by Chris Mosher [ 29/May/15 ]

We still seeing this happening under Gradle 2.4. Stack trace attached.

Comment by Luke Daley [ 31/May/15 ]

issue not fixed.

Comment by Alban [ 08/Jul/15 ]

We're running into this issue too with 2.4. Got a "Failure initializing default system SSL context" message when downloading dependencies when using the --parallel parameter.

Comment by Luke Daley [ 12/Jul/15 ]

This is actually blocked on https://issues.gradle.org/browse/GRADLE-3250, which is in progress.

Comment by Alban [ 08/Dec/15 ]

Oh, I've been waiting so long for this one! I'll be able to re-parallelize some tasks now. Thank!

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