How to make gradle use correct JDK when compiling?

Question

We use gradle to build our Java projects, some are based on JDK7 and some on JDK8. I know of the org.gradle.java.home property, but it seems flawed to me.

If I configure it in '~/.gradle/gradle.properties' this will force me to use the same JDK for all my gradle projects.

If I configure it in '/my-git-project/gradle.properties' this will force me to put a reference to a local JDK installation in a shared Git repository. The path to JDK do not belong there.

What I basically would like to have is something similar to this in '~/.gradle/gradle.properties':

systemProp.jdk8=/my/local/path/to/jdk8
systemProp.jdk7=/my/local/path/to/jdk7

And under source control in '/my-git-project/gradle.properties':

org.gradle.java.home=$systemProp.jdk8

What's the best solution/workaround for this?

Betti

This is really a java question rather than a gradle question, I fail to see how gradle could handle this if java does not provide a mechanism for switching jdks or querying available jdk versions - and it does not. The exact same problem exists with any java based tool, everything depends on JAVA_HOME. – Excusatory

I for one cant wait for SDKman to support JDKs – Excusatory

Answer 1

This is more of a process question than a Gradle or Java question. Ultimately, you have to force everyone to specify their various JAVA_HOMEs without being onerous. You have several options:

1. Command line: ./gradlew -Dorg.gradle.java.home=/path_to_jdk_directory

But, of course, now everyone has to type some hideous junk into their command line every time they run a build.

2. gradle.properties and check-in the path. Then, make everyone use the same path.

Not everyone's going to want to use the same path, especially if you have Mac/Unix and PC users.

2b. Instead of using an identical path, everyone could modify their local gradle.properties with their custom values, then never check-in their modifications.

Primary problem: someone's totally going to check-in their local values and screw up CI and everyone else.

3. gradle.properties.template check-in, everyone creates their own gradle.properties; put gradle.properties in your .gitignore

This might be your best bet. You have a template file that you check-in, but everyone has to copy it to gradle.properties and fill in their specific values. You'll need to setup your CI to do something similar, or check-in something like gradle.ci.properties and have CI use that. But, everyone only has to do this once instead of once per build. Unfortunately, they will have to update their personal file every time the template changes (unless you write some code to do that).

Chemosphere

I'm doing (3) and it is finee. Also compileOptions { } closure with sourceTarget and compileTarget enumerations if you are coming at this from an Android perspective. – Pendulous

Answer 2

We cope with that problem like this:

The one who starts the build is responsible for properly setting JAVA_HOME

On developer machines that may be brittle. But it works perfectly, if you build and deploy from a dedicated buildserver.

Tragus