Windows Subsystem for Linux not recognizing JAVA_HOME Environmental Variable

Question

I'm trying to get WSL to recognize my windows installed environmental variable of JAVA_HOME. I attached of what I have in my bashrc and what I have in my windows environmental variables along with outputs from cmd and bash.

What's at the end of my bashrc:

export JAVA_HOME="/mnt/d/Program Files/Java/jdk-11.0.1"
export PATH="/mnt/d/Program Files/Java/jdk-11.0.1/bin:$PATH"

CMD INPUT/OUTPUT:

C:\Users\jaall>javac --version
javac 11.0.1

BASH INPUT/OUTPUT:

myubuntu_name@DESKTOP-LUK3BII:~$ javac --version

Command 'javac' not found, but can be installed with:

sudo apt install default-jdk
sudo apt install openjdk-11-jdk-headless
sudo apt install ecj
sudo apt install openjdk-8-jdk-headless

I've been stuck on this for awhile and can't figure it out or find a working solution online. Thanks!

Answer 1

As Biswapriyo suggested, you should use WSLENV.

1. Open PowerShell. Then set JAVA_HOME to the path to your java installation.

2. In your case, run setx JAVA_HOME "D:\Program Files\Java\jdk-11.0.1"

You should see a message that says "SUCCESS: Specified value was saved".

3. Then run setx WSLENV "JAVA_HOME/p".

You should see the success message again.

4. Type 'env' into your WSL bash prompt.

You should see JAVA_HOME correctly set at this point.

Note: If step 2 doesn't work, you might want to changing the path to JAVA_HOME to include the \bin folder.

Answer 2

I originally had Maven working in Windows attempted to run Maven in WSL2 and tried all of the previous solutions, but would consistently get the following no matter what I set for JAVA_HOME and PATH:

$ mvn -v
The JAVA_HOME environment variable is not defined correctly
This environment variable is needed to run this program
NB: JAVA_HOME should point to a JDK not a JRE

The issue was I was trying to use a Windows version of the JDK in the WSL2 Linux kernel. To fix this I ended up having to install a Linux version of the JDK (version 11) in the WSL as follows:

$ sudo apt update
$ sudo apt install openjdk-11-jdk
$ sudo update-alternatives --config java
There is only one alternative in link group java (providing /usr/bin/java): /usr/lib/jvm/java-11-openjdk-amd64/bin/java
Nothing to configure.

Then take the path for your JDK and use it to create JAVA_HOME and update PATH by appending the following in .profile

export PATH="/usr/lib/jvm/java-11-openjdk-amd64/bin/java:$PATH"
export JAVA_HOME="/usr/lib/jvm/java-11-openjdk-amd64"

Now close and reopen WSL2 and when your try again:

$ mvn -v
Apache Maven 3.6.3
Maven home: /usr/share/maven
Java version: 11.0.13, vendor: Ubuntu, runtime: /usr/lib/jvm/java-11-openjdk-amd64
Default locale: en, platform encoding: UTF-8
OS name: "linux", version: "5.10.16.3-microsoft-standard-wsl2", arch: "amd64", family: "unix"

Answer 3

TL;DR: In WSL, you must use javac.exe since it is a Windows binary. Simply typing javac will not work, even if the path is set up correctly. If that doesn't work, try adding ../bin to the end of your JAVA_HOME variable.

Using Windows Binaries & Environment Variables in WSL

There's a much easier way to make Windows and WSL utilize the same JavaSDK binary, you just need to set up a few things first. Best of all, if you have JavaSDK installed on Windows, you do not need to install Linux binaries.

Check WSL Permissions and Directory Link (Optional, but recommended)

In WSL, list symbolic links on PC:

ls -l /mnt

If any drive is owned by root, perform your WSL dev work in /mnt/c/Users/<UserName>

Personally, I create a development directory in Windows and add a symbolic link to the directory in WSL:

ln -s /mnt/d/dev/environment/ ~/dev

cd dev now brings you to your development directory.

Ensure Java for Windows works

Open PowerShell/cmd.exe from any directory and enter: java --version

You should get a list of JRE info:

openjdk 11.0.4 2019-07-16 LTS
OpenJDK Runtime Environment Corretto-11.0.4.11.1 (build 11.0.4+11-LTS)
OpenJDK 64-Bit Server VM Corretto-11.0.4.11.1 (build 11.0.4+11-LTS, mixed mode)

Your version might be different, the important part is that the system knows where to find Java. If you get an error, ensure your Windows Environment variables are set correctly:

• JAVA_HOME as an Environment Variable, and
• JAVA_HOME/bin as a Path variable.

Setting Variable in WSL

The best place to put the next lines of code are in your .bashrc file, but if you have a ./bash_profile or /etc/profile structure set up, you can put it there.

# Shared environment variables
# Use 'java.exe <args>' to utilize Windows Java binaries from within WSL.
export JAVA_HOME=/mnt/d/Java/jdk11.0.4_10

While we're at it, let's add Maven too:

export MAVEN_HOME=/mnt/d/software/apache-maven-3.6.2

I have my WSL, Java, and all my other dev tools set up on my second HDD which is not a system drive, ensure that your location matches your JAVA_HOME path in Windows.

For instance, if in Windows, Java is located at: C:\Java\jdk8.0 The corresponding WSL mount point is: /mnt/c/Java/jdk8.0

Executing

Important: Use java.exe <args> in WSL instead of java <args> Say you just wrote CompareTwoStrings.class and want to compile and run it using the Windows binaries. You can do it from a Windows shell or WSL.

Windows PowerShell/cmd:

javac GetStringLength.java
java GetStringLength

WSL:

javac.exe GetStringLength.java
java.exe GetStringLength

Using java <args> in WSL will result in a Command 'java' not found error. That is because running windows binaries from within WSL requires that the .exe extension is used in the command.

Simplicity

We don't want to install a second copy of Java specific to WSL and waste that precious disk space, so we're going to call the Windows binary from the WSL shell. This is a great benefit of WSL—WSL1 in particular—in that it can interact (almost) flawlessly with the Windows File System.

NOTE: In order to run a program, it must either be a Path variable, or be run from within it's containing folder.

Hopefully that works as easily for you as it did for me. Just remember to use the correct command depending on what OS binary you're running. This took me about 10 minutes to get set up, and has been a lifesaver for cross-compiling and general ease-of-use.

Answer 4

Since I've never been able to share variables between the 2 systems easily, I created a simple bash function which can easily retrieve (and define, if asked to) any Windows Environment variable. It also takes care of paths so they get converted from Win32 to Un*x-like.

I added this to /etc/bash.bashrc:

winenv()
{
  if [ "$#" == "0" ] || [ "$1" == "--help" ]
  then
    echo $'\n'Usage:
    echo $'\t'winenv [-d] WINDOWS_ENVIRONEMENT_VARIABLE_NAME
    echo $'\t'-d: Defines environment variable in current shell
    echo $'\t    Note that paths will be translated into un*x-like\n'
    return
  fi
  local IFS='$\n'
  local PATH_TO_TRANSLATE=$1
  [ "$1" == "-d" ] && PATH_TO_TRANSLATE=$2
  local VAR=$(cmd.exe /c echo %${PATH_TO_TRANSLATE}% | tr -d '\r')
  local NEW=$(wslpath -u "${VAR}" 2>/dev/null || echo ${VAR})
  echo "${PATH_TO_TRANSLATE} = ${VAR} -> ${NEW}"
  [ "$1" == "-d" ] && export "${PATH_TO_TRANSLATE}=${NEW}"
}

And all I have to do to display one is to call winenv PROGRAMFILES (for example)
Or if I expect to export it, I just have to add a -d argument before the variable name as in winenv -d WINDIR.