34

I'm trying to figure out which environment variable java uses to find/detect the JRE used by C:\ProgramData\Oracle\Java\javapath\java.exe.

As per Oracle's design, the only files I have in the C:\ProgramData\Oracle\Java\javapath\ are

  • java.exe
  • javaw.exe
  • javaws.exe

If I set my JAVA_HOME to empty or to some random folder, running an application with java.exe still works. So I can only assume that it isn't using the JAVA_HOME value. So how does it find the JRE folder? Does it default to something specific? I have no JRE_HOME var set either.

Maciej Los
  • 8,468
  • 1
  • 20
  • 35
Eric B.
  • 23,425
  • 50
  • 169
  • 316
  • Did you look at you PATH environment variable? – OldProgrammer Mar 28 '18 at 17:04
  • 1
    @OldProgrammer sure. I have other java paths defined there. But will java.exe use the path env variable to find the necessary libs it requires? I would have expected it to need the JAVA_HOME var - and not expect it to use that PATH var. Normally, I would expect the PATH to be used to find executables. Furthermore, if I clear the PATH var to only have C:\ProgramData\Oracle\Java\javapath\ defined, java still runs. – Eric B. Mar 28 '18 at 17:06
  • I believe beside the path variable the java.exe in system32 used a regedit lookup. This behavior cost me a lot of hours of my life... – 98percentmonkey Nov 18 '18 at 11:31
  • @EricB. In order to run any programs in Windows or Linux, either the file is in your current directory, or you provide the full path to the executable file, or the directory is included in the PATH environment variable. – Clon Nov 18 '21 at 08:04

5 Answers5

38

As of 2018, and specifically with regards to Oracle Java, you might find your Java runtime installed in one of two ways:

Regular Directory with File Symlinks inside

If you look at the files in C:\ProgramData\Oracle\Java\javapath\ you will see that they are actually symlinks to specific java binaries.

2015-11-13  06:11 PM    <SYMLINK>      java.exe [C:\Program Files\Java\jre1.8.0_65\bin\java.exe]
2015-11-13  06:11 PM    <SYMLINK>      javaw.exe [C:\Program Files\Java\jre1.8.0_65\bin\javaw.exe]
2015-11-13  06:11 PM    <SYMLINK>      javaws.exe [C:\Program Files\Java\jre1.8.0_65\bin\javaws.exe]

Directory Junction with regular Files inside

Using the latest (64! bit) install of Java 8 actually prepends onto the system path another location: c:\Program Files (x86)\Common Files\Oracle\Java\javapath. This time, the javapath itself is the junction:

2018-07-21  05:59 PM    <JUNCTION>     javapath [C:\Program Files (x86)\Common Files\Oracle\Java\javapath_target_172906453]
2018-07-21  05:59 PM    <DIR>          javapath_target_172906453

And now, interestingly, the java.exe etc. in the javapath_target_... folder are not symlinks. These files find JRE and JDK versions using this registry location:

[HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment]
"CurrentVersion"="1.8"

[HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment\1.8]
"JavaHome"="C:\\Program Files\\Java\\jre1.8.0_65"
Chris Becke
  • 34,244
  • 12
  • 79
  • 148
  • 2
    Interestingly I tried changing the version via the registry, and then get `Error: Registry key 'Software\JavaSoft\Java Runtime Environment'\CurrentVersion' has value '11.0.5', but '1.8' is required.` – OrangeDog Nov 11 '19 at 12:43
22

This will give you an idea:

java -verbose | more
access_granted
  • 1,807
  • 20
  • 25
  • 2
    Thanks. It pointed me to the c:\Program Files(x86)\java folder. I'm still not sure I understand why it defaults to there, but at least I know where it is looking now. – Eric B. Mar 29 '18 at 14:28
16

These "new" JDK 8 / 64-bit behavior is so obfuscated, I could not guess why my application would not start, because I had the JDK (with the private JRE) and every path variable setup, still no start. After some time I installed JRE8 alone and it worked. Firstly the regedit - keys are only written by the public JRE.... Ok.

Then I wanted to know which Runtime the app used, I renamed all java* .exe, yet it still worked64-bitI renamed all-new regedit keys. It still worked...

End of story: with Windows 64 the regedit keys are in HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft (32bit) and

HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\JavaSoft (64bit)

and my app worked because

HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\JavaSoft\Java Runtime Environment\1.8\RuntimeLib\ 

pointed to jvm.dll which referenced a symlink. I need a beer, I want another Job :-)

Here is a nice link, which explains the Regedit-Keys and the different "discovery methods" which Java uses to find the newest installed version:

http://mindprod.com/jgloss/registry.html

Still the SYSLink - Change with JDK8 seems to be an undocumented change which was introduced before JRE8u171.

My sysLink Path was C:\Program Files (x86)\Common Files\Oracle\Java with was actually a Junction to a subdirectory. And the JDK8 installer copies the java*.exe files into Windows\System32\ btw.

More Infos:

Sorry for my rant, I'm so frustrated right now. I hope it helps somebody else.

cb4
  • 6,689
  • 7
  • 45
  • 57
98percentmonkey
  • 545
  • 7
  • 18
7

Try java -verbose with findstr

Example:

C:\>java -verbose 2>nul | findstr /I opened
[Opened C:\Program Files\Java\jre1.8.0_201\lib\rt.jar]

(Or try just java -verbose -- which will output a LOT of text. And the path to your Java standard JARs will be included several times.)

Try reg query with /s

Example:

C:\>reg query "HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment" /s

HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment
    CurrentVersion      REG_SZ    1.8
    BrowserJavaVersion  REG_SZ    11.201.2

HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment\1.8
    RuntimeLib      REG_SZ    C:\Program Files\Java\jre1.8.0_201\bin\server\jvm.dll
    JavaHome        REG_SZ    C:\Program Files\Java\jre1.8.0_201
    MicroVersion    REG_SZ    0

HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment\1.8.0_201
    JavaHome        REG_SZ    C:\Program Files\Java\jre1.8.0_201
    MicroVersion    REG_SZ    0
    RuntimeLib      REG_SZ    C:\Program Files\Java\jre1.8.0_201\bin\server\jvm.dll

HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment\1.8.0_201\MSI
    INSTALLDIR      REG_SZ    C:\Program Files\Java\jre1.8.0_201\
    JU              REG_SZ
    OEMUPDATE       REG_SZ
    FROMVERSION     REG_SZ    NA
    FROMVERSIONFULL REG_SZ
    PRODUCTVERSION  REG_SZ    8.0.2010.9
    EULA            REG_SZ
    JAVAUPDATE      REG_SZ    1
    AUTOUPDATECHECK REG_SZ    1
    AUTOUPDATEDELAY REG_SZ
    FullVersion     REG_SZ    1.8.0_201-b09


C:\>

Try Get-Command java

Note: If you just care about the version number, then you might want to try PowerShell's Get-Command:

PS C:\> Get-Command java | ft -AutoSize

CommandType  Name      Version    Source
-----------  ----      -------    ------
Application  java.exe  8.0.201.9  C:\Program Files (x86)\Common
Files\Oracle\Java\javapath\java.exe
StackzOfZtuff
  • 2,534
  • 1
  • 28
  • 25
0

I recently ran into this as I have added in JAVA 9, 11, and 17 along with my previous JAVA 6, and 8 versions. I incorrectly assumed that env variables hadn't changed with the newer releases, but I was obviously wrong.

When I ran java -version it returned JAVA 9 and javac -version returned JAVA 17.
I incorrectly tried to add a %JAVA_HOME% variable, as I had always done in pre-JAVA 8 versions under the Windows Environment Settings. However, despite moving that addition to the front of the PATH, it didn't change anything!

As already explained, this Windows folder: C:\ProgramData\Oracle\Java\javapath is where java has 3 symbolic links set that will override the PATH changes you make and sure enough it was pointing to the JAVA versions I returned from -version on java and javac.

I found two solutions here at: JDK 8 and C:\ProgramData\Oracle\Java\javapath

How to switch JDK version in cmd more flexibly You can either prepend your own directory to the PATH to overwrite the Oracle one, or follow the convention to append to the end of PATH variable like always did. I prefer the second one, here is how to do it.

The second solution uses two batch files with a env variable JAVA_HOME setting similar to what I had always used.

I'm posting this to add in a solution in case someone needs a workaround.

James Drinkard
  • 15,342
  • 16
  • 114
  • 137