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

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

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 3

Since I've never been able to share variables between the 2 systems easily, I creayed 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-line.

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 paths\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.