9

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 ?

anjanb
  • 12,999
  • 18
  • 77
  • 106

2 Answers2

3

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.

Andrew Henle
  • 32,625
  • 3
  • 24
  • 56
  • `java.exe` is not a JVM binary. It's just a [simple launcher](http://stackoverflow.com/questions/26020872/totally-confused-with-java-exe/26025656#26025656). – apangin Jun 20 '16 at 21:00
  • @apangin And once one file in what's supposed to be a coherent package is proven to come from the wrong package, *every* file in that package is suspect. If you run into a problem running a Java 7 `java.exe` and the rest of the JVM installation is of unknown provenance - like in the question - just try filing a bug report with Oracle. It's *broke*. Trying to see how long you can get away with it being *broke* is just plain *wrong*. You fix it *as soon as you can* because you *don't know* what will happen, then figure out what went wrong so you don't do it again. – Andrew Henle Jun 20 '16 at 21:58
  • You are right in general. However, in this particlar case the problem has already happened, and OP is trying to evaluate the consequences. What I'm saying is that the consequences are not that bad, since the launcher is a separate component of JRE which communicates to JVM through a standardized API. JVM is known to work even without a launcher. – apangin Jun 20 '16 at 22:25
  • @apangin - The OP isn't *evaluating* anything. He's *hoping* he didn't break anything. You'd have to run the entirety of Oracle's internal Java regression tests against the hybrid JVM in question to even get an idea if anythings broken or not, and even those allow a lot of bugs by. "It's worked so far." is just stating a hope that it will continue to work. – Andrew Henle Jun 21 '16 at 15:08
  • I would not call it *"hybrid JVM"*, because as I've told `java.exe` is not a part of JVM at all. Your cautions are totally understood, however, they are based purely on general words. If you are aware of any specific issues, please edit the answer to mention them, and I'll vote up for it. – apangin Jun 22 '16 at 10:52
  • @apangin The process the OP used to copy the entire JVM was supposed to copy from *one* JVM install. It didn't do that, so *everything* about the resulting JVM is suspect until the exact breakage that caused the creation of the hybrid JVM is determined. Since the exact cause has *not* been posted, the JVM consists of components from unknown sources - and it's not just `java.exe` that's suspect - it's *all* suspect. *Hoping* the hybrid JVM continues to work is just that - *hope*. If *hope* is high enough of a standard for you, that's on you. I try for something more stringent. – Andrew Henle Jun 22 '16 at 11:11
  • @apangin And you have it backwards - I don't have to prove there are problems in such a hybrid JVM. Because it's a suspect installation, you have to prove there *aren't*. Again - try filing a bug with Oracle on that JVM. Tell them it consists of binaries from Java 7 and Java 8 and see how far you get. – Andrew Henle Jun 22 '16 at 11:14
1

java.exe is a simple launcher. It does not contain JVM or Class Library code. Its primary function is just to locate a JRE and to load jvm.dll with the arguments passed in the command line.

You can start a JVM using the Invocation API even without java.exe.

java.c log tells there are not really much changes in the launcher between JDK 7 and JDK 8. E.g. there is a launcher support for JavaFX applications and a few fixes for better argument validation. That's it. So if your application starts fine with JDK 7 launcher, there is apparently nothing to worry about.

Community
  • 1
  • 1
apangin
  • 92,924
  • 10
  • 193
  • 247