4

What are the differences between java -version and java -fullversion?

The two do not seem to line up on my machine.

C:\Users\kmort>java -fullversion
    java full version "1.8.0_20-b26"

C:\Users\kmort>java -version
    java version "1.8.0_25"
    Java(TM) SE Runtime Environment (build 1.8.0_25-b18)
    Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode)

This link (at the bottom) seems to indicate that fullversion simply includes the build number. If that's true, what to I end up with a different answer when I run the two?

Note that this documentation neglects to refer to fullversion entirely.

I am running on 64 bit Windows 7. If it helps, here is a screenshot of the JDK and JRE installs I have on my machine.

enter image description here

Update

When I run Window's where command, I get the following:

C:\Users\kmort>where java
C:\Windows\System32\java.exe
C:\ProgramData\Oracle\Java\javapath\java.exe
C:\Program Files\Java\jdk1.8.0_25\bin\java.exe

The problem is with the java.exe located in System32. If I rename that one to something else, things work as expected. And the Oracle one is just symbolic links to the last one.

So now the question is why does this happen with a java.exe in my System32 folder? (My endgame will be to delete java.exe from the System32 folder, but I'd like to understand what's going on first.)

Update 2

Using Process Monitor, I can see that when I run either command on the offending C:\Windows\System32\java.exe this is the executable that is run (see the screenshot of it calling LoadImage on C:\Windows\System32\java.exe). There are also a few references to C:\Windows\SysWOW64\java.exe in both of them. I'm not sure why.

enter image description here

Also note that it appears my registry is correct. Currentversion is 1.8. enter image description here

One other note, the timestamp on C:\Windows\System32\java.exe is on a day that I know I installed a JRE.

kmort
  • 2,848
  • 2
  • 32
  • 54
  • My initial thoughts are that this installation of Java is not correct. My second though is that, perhaps, java.exe is smart enough to just check the Windows registry instead of "itself" and it is reporting what is there. Check your JavaSoft keys to see what the installed 64-bit JREs are on this system. And I just looked at your posting more closely and see you are running out of System32 though it is reporting 64-bit server VM. Be sure this is the one you are NOT running. –  Mar 05 '15 at 17:21
  • @jdv I've looked at the registry and pasted a screenshot above. It seems okay to me. Am I missing something? And System32 is the one it's running. I am going to delete it when I understand why the version numbers this critter is reporting are different. – kmort Mar 05 '15 at 18:43
  • thanks for that. It was for certain a true outlier guess only, but at least we've ruled it out. If you get the same results running java with the full pathname for both invocations, I have no intelligent explanation. –  Mar 05 '15 at 18:46
  • I don't have an answer. It turns out that the "system" VMs are just pointers to whatever the latest VM is in the Windows registry. The system VMs do not get updated with an Update Install, either. I'm also reading that recent full versions of Java 8 installs REMOVE both system executables anyway. So what we are seeing here might be related to how these executables are finding the "latest" when given different options and/or an artefact of multiple Java 8 installations or updates run, leaving these system executables in a strange state. I have no real answer. It's a stumper. –  Mar 05 '15 at 21:32

2 Answers2

2

After much back and forth, it looks like this is a side-effect of Java "update" installs not updating the Java executables in the System directories.

Once upon a time, 1.8.0_20-b26 was installed to this machine, and it dutifully put a full JAVA_HOME down, registry entries for this version, updated the latest VM in the registry, and also put the /special/ java.exe in %WinSysDir%

At some point the JVM was updated, probably through the Java updater tool, and probably not with a full installer (the OP can confirm.)

This create a new JAVA_HOME, updated the registry, and probably even deleted the old _20 installation. But, here's the kicker: it did not delete the java.exe in %WinSysDir%

@kmort ran POSIX strings on the executable and saw that "1.8.0_20-b26" was, indeed, buried in that old executable.

So, what is happening is that for the -version option it would check the registry for the latest JVM and invoke that with the option (or just return the FullVersion from the registry -- we don't know until we trace the system calls) [It appears to actually call the executable --jdv]. But for -fullversion it would just return the static string inside the executable!

I suspect that the fact that -version can take an optarg means the processing for these options is totally different.

The solution is to:

  1. Just delete the java.exe in %WinSysDir%

  2. Live with it because it is probably harmless (unless -version processing is actually invoking a different JVM, in which case all bets are off)

  3. Reinstall Java 8 from scratch using the latest MSI from Oracle.

(3) should replace the java.exe in %WinSysDir% (and the WOW64 system java.exe). (1) is probably totally fine. (2) is probably a bug if -version causes java.exe to wander off and invoke the real JRE that isn't the latest.

  • Thanks jdv. The timestamp on the `C:\Windows\System32\java.exe` file is on a day I know I installed a JRE, so I'm pretty sure it came from Oracle. – kmort Mar 05 '15 at 18:45
  • @kmort how about that. Good to know. This explains things a bit more: http://stackoverflow.com/questions/11063831/what-is-the-difference-between-system32-java-exe-and-program-files-java-jdk1 I do not have the system32 java for some reason, but I install and update JREs constantly. It must have been removed at some point. What is interesting is that the System32 java IS derived from the Windows registry. Reading further, the -version option actually takes an option to SELECT the version. All these things I did not know until now. So this question is great! –  Mar 05 '15 at 18:48
  • Hmm. So some folks say that `C:\Windows\System32\java.exe` is a "dummy" file that picks what the registry has set and points at that, others say it's a copy of the actual Java.exe that the JRE installs. A simple checksum reveals they are not the same (doesn't match 32 or 64 bit versions). So I'm leaning towards a "dummy", but that doesn't explain why I get different results for the version based on the command line I pass in. I'm not worried about 32 vs 64 bit, I'm worried about the actual version number difference. Thanks jdv. – kmort Mar 05 '15 at 20:41
  • Did you try running the two options with absolute paths. While I'd normally agree that whatever is on your path is whatever is on your path, but in this case something is very odd. –  Mar 05 '15 at 20:50
  • Yes (well, not with absolute paths, but from each folder, which means Windows will find that one first). All of the ones in `Program Files`, both 32 and 64 bit function as intended. The weird ones are `C:\windows\system32\java.exe` folder and `C:\windows\SysWow64\java.exe`. They both do the odd number reporting. I wish I could figure this out. :-) – kmort Mar 05 '15 at 21:01
  • It is almost certainly the registry, or a combination of whatever the "system" java executables do when run in combination with the registry values. Since we know they check the registry, what is your "HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java RuntimeEnvironment\1.8". These two executables are definitely special. I am as puzzled as you are. –  Mar 05 '15 at 21:10
  • Let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/72370/discussion-between-jdv-and-kmort). –  Mar 05 '15 at 21:14
1

I tried reproducing the results and I got the same java version on both the commands. So I think, having multiple JREs in your Java folder might be causing inconsistencies in your results.

cmd results

enter image description here

My jre inside C:\Program Files (x86)\Java

enter image description here

Prudhvi
  • 2,276
  • 7
  • 34
  • 54
  • All my other machines have the same results too. Just this one is wonky. I tested your theory by moving the extra JRE/JDK packages, but the issue persisted. I thought maybe it was because of the 32/64 bit ones, but the issue still persisted. Good thoughts though. Thanks. :-) – kmort Feb 26 '15 at 22:18
  • @kmort Instead of moving the extra JRE/JDK packages, try deleting them and check the results. I hope this works. – Prudhvi Feb 26 '15 at 22:23
  • 1
    I'm not sure how that would make a difference. My path didn't change and I moved the JRE/JDK packages out of the set path. Unless there's some weird mechanism I'm not aware of, there's no way my command line resolved to the packages I moved. Am I missing something? – kmort Feb 27 '15 at 14:25