Implications of Old version of Java.exe (7.1) using new version of runtime(8.x)

Question

We have a situation where our application embeds a JRE. The application, by mistake, ships with a mashup (7.x version of java.exe and 8.x version of the rest of JRE).

I can confirm that the process running the v. 1.7 java.exe uses the v. 1.8 java runtime using Process Explorer. I'm surprised that the runtime or the binary didn't detect the anomaly and abandon JVM creation!

What are the implications of the same ? Security issues ? Stability issues ? I haven't gone through the source code for java.exe. From my preliminary investigations of java.exe binary, I can see that it is more than a stub. It calls out to 100 different KERNEL32.DLL APIs apart from USER32.dll, ADVAPI32.dll, COMCTL32.dll.

Sure, we can(and we will) fix the mistake. But are there implications for the several current production systems that use the above anomaly ? if yes, what are they ?

Answer 1

What are the implications of the same ? Security issues ? Stability issues ?

All of those.

The JVM binary (java.exe in your case), the shared objects/DLLs that come with it, and the JAR files that implement the Java side of things all come in a combined package that is not designed nor meant to be run as anything but a combined package.

Specific lists of compatibility issues between Java 7 and Java 8 are known external issues between coherent versions of the entire JVM package.

You've added internal incompatibilities of an incoherent Java installation to those known external incompatibilities. There's no way to get a list of those. It's almost certain that no one even tries to keep track of such things.

You have no idea what should work, what will work, nor how long it will work even if it does appear to work.