You’ve 2+ JDKs installed on your machine? Ok, but be careful

header by @virgilcayasa from Unsplash

I’m writing this article to share my story about an issue on my machine I’ve spent about 2 days solving it.

Tl;DR

if you have more than 1 JDK installed on your windows machine, make sure to configure the one which is widely used by your projects the default on Windows Registry not just the PATH or JAVA_HOME environment variables, and configure the other JDKs on demand per each project/IDE.

On my windows machine, I have two JDKs installed or technically speaking one JDK & one JRE, they are JDK 13.0.1 & JRE 1.8.0_271 respectively. I’m using JDK 13 99% of the time, it is the default one on the PATH environment variable, almost all of the projects on my machine have been built with it, so that, sometimes I forget that I have JRE 1.8 installed! everything is fine so far.

Note: You might ask why I just don’t simply get rid of JRE 1.8? You’re right but that will lead us to another headache which is beyond the scope of this article

The problem appeared when I decided to download gradle-profiler tool in order to benchmark gradle build speed of a Project. I had downloaded the latest release and then I ran gradlew installDist from the command line within the dir we’ve just installed, it gave me the following error 💥💥:

Execution failed for task ':client-protocol:compileJava'.
> Could not find tools.jar. Please check that C:\Program Files\Java\jre1.8.0_271 contains a valid JDK installation.

Why would gradle-profiler want to use JRE 1.8 path? Why it just don’t use JDK 13 like every other single project on my machine?

Luckily we know where this exception is thrown. In a sub-project :client-protocol ‘s compileJava task which is basically provided by java gradle core plugin.

typing the error message in the search box of github within gradle repository would navigate us to a class called JdkTools where an IllegalStateException is thrown with a message that matches our error message, the interesting part in that is that JdkTools class uses a function called jvm.getJavaHome to know about the java home on your machine, So, what does this method actually do? Let’s dig into Jvm class to find out.

We can see that getJavaHome() returns a private javaHome field which got initialized on creating the constructor of Jvm instance with the value of System.getProperty("java.home")

Copying System.getProperty("java.home") & running it locally on my machine would print:

C:\Program Files\Java\jre1.8.0_271

As you can see, here is the core of the problem. why does “java.home” key is pointing to JRE 1.8 path? how can JRE 1.8 path be discovered when I have JDK 13 configured by default? Just to make sure I’ve nothing wrong up to this point I ran javac -version & java -version. both gave me the correct JDK 13 which is on my PATH .

Also, I’ve checked System Properties Oracle official doc and we can see that “java.home” is:

Installation directory for Java Runtime Environment (JRE)

So, according to the documentation, it should point to JAVA_HOME\bin path on my machine, but Obviously, this is not the case here.

I started to make use of traditional solutions such as:

• override “java.home” location explicitly from the command line by using -Djava.home="C:\\Program Files\\Java\\jdk-13.0.1\\bin"
• running the given task from an IDE like Intellij or Eclipse and adding -Djava.home="C:\\Program Files\\Java\\jdk-13.0.1\\bin" to VM parameters within Run Configurations
• override “java.home” location programmatically by using System.setProperty("java.home", "JRE_13_path")
• Download the missing tools.jar manually and add it the JRE 1.8 path

Unfortunately, all of those solutions & other naive solutions didn’t make any difference. I started to burn out & giving up but I’ve remembered one last thing I could try which is Windows Registry.

I know that some apps take advantage of Windows Registry to store some preferences in a form of key/value. And here is where I have discovered that Java Runtime Environment is being set to JRE 1.8 path, I’ve changed it to JDK 13 path, restarted my machine and finally everything worked like a charm!

Conclusion:

I don’t know but I wasn’t aware that windows registry could be the root of the problem. I’ve searched online & got many solutions but none of them was talking about the windows registry. even the tutorials that help you install java on your machine, they only talk about adding java to your PATH after installation. Anyway, I just wanted to document my story debugging this issue to make sure I’m not going to fall in that mistake twice. Also, to give a reference for anyone who might get stuck by a similar problem.