This is also important for STS/Eclipse integration. I have multiple reports of people having issues running Gralde tasks that require the Java compiler. Presumably the problems are due to gradle finding a JRE on their system and using that instead of the JDK.

There currently is no mechanism at all for the IDE to specify which JAVA_HOME gradle ought to use. So no way for me to really fix the problems those users are experiencing.

Blocked issues in STS:
https://issuetracker.springsource.com/browse/STS-2276
https://issuetracker.springsource.com/browse/STS-1756 (really an older duplicate of 2276)

I guess we need to take on GRADLE-1240 pretty soon.

Thanks for reporting!

Denis, I think this is a duplicate of GRADLE-1240. Pleas reopen if it is not. Cheers!

Hi,

I don't see that the current task is a duplicate of GRADLE-1240. The current one asks an ability to define jdk to use by gradle (e.g. there are various java5, java6 and java7 versions available at the client's machine). The later talks about configuring jvm settings for the selected jdk.

Btw, it seems that I don't have enough rights at the tracker to reopen the ticket.

I agree with Denis, calling it a duplicate may be stretching it.

However on the bright side. I do think this issue is now resolved. I even implemented something in STS already that allows the user to pick their JVM to use for Gradle. And I'm now able to pass this info to the tooling API with no problem.

The method in the API is this one:
org.gradle.tooling.LongRunningOperation.setJavaHome(File)

Agreed, duplicate is a stretch. We always considered the args and java location as a same thing internally

Denis, did you notice the org.gradle.tooling.LongRunningOperation.setJavaHome(File) method? Does it solve the problem?

Yes, I think it addresses the problem.