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/topic...
----------------------------------------------------------------------------------------
[1] http://forums.gradle.org/gradle/topics/unable_to_find_a_javac_compiler_under_mac_os_with_java_1_7_gradle_1_1