Relationship between the Java runtime used to run the tooling API and the JAVA_HOME

Old Forum Archive
1

I talked about this strange behaviour with Kris De Volder of Spring Tool Suite: https://issuetracker.springsource.com/browse/STS-2276

I’m seeing an unexpected behaviour on how the JAVA_HOME setting is taken by the tooling API. My scenario is the following: - running Eclipse/STS with JRE 7 - running a task from Eclipse/STS on my project, after setting the JAVA_HOME option within Eclipse to JDK 6 (this is using the tooling API to set the JAVA_HOME for the Gradle daemon, I guess, something which is somewhat working since Gradle 1.0RC1)

What I observe is that: - the JAVA_HOME is correctly set by Eclipse/STS, because the compiler is found by Gradle to compile my project (if I don’t set JAVA_HOME, Gradle complains it can’t find a suitable JDK with a compiler) - however, it seems like Gradle is providing the Java 7 API (rt.jar) to the compiler, instead of the one coming from the Java distribution under JAVA_HOME (i.e.: Java 6 in my case); in fact I see many messages like:

warning: java\lang\Object.class(java\lang:Object.class): major version 51 is newer than 50, the highest major version supported by this compiler.
It is recommended that the compiler be upgraded.

or like:

<myclass> is not abstract and does not override abstract method getParentLogger() in javax.sql.CommonDataSource

The latter message happens because we have a class that implements javax.sql.CommonDataSource and which is not Java 7-ready (in fact, the method getParentLogger() is in javax.sql.CommonDataSource since Java 7).

So, it seems like the JRE used to run Eclpise/STS (and hence the Gradle daemon launched by the tooling API) in some way is used also to compose the classpath for the compiling tasks, even if the compiler is taken from another Java instance thanks to the use of the JAVA_HOME setting.

This message is to ask if this is a known issue, if there are workaround or if an issue should be opened. I’m using Gradle 1.2.

2

The first thing to do is to rule out that this is caused by http://issues.gradle.org/browse/GRADLE-2460 (for details, see my last comment on that issue). You can do so by trying a recent nightly distribution.

3

Hi Peter! Yes, using gradle-1.3-20121016220018+0000-bin.zip in STS seems to do the trick! So it must have been the same problem outlined in GRADLE-2460. Thank you very much for your help!

4

Hi Peter! Yes, using gradle-1.3-20121016220018+0000-bin.zip in STS seems to do the trick! So it must have been the same problem outlined in GRADLE-2460.

Thank you very much for your help!

5

That’s good to hear. The 1.3 release is only a few weeks away.