I really hope this is the right place to post this question.
Anyway, I need to run 2 versions of Java on the same workstation to run an application. Both versions of Java are old, and these versions can't be changed (Vendor is several years behind with their application). Anyway, here's the run down (I have to be somewhat elusive to some of the details due to the nature of working in a government facility):
We have this application that I'll call the Ninja Application, in which the client was written in Java. The Ninja Application has 2 instances - a live instance and a test instance. Both are important for day to day functions as there are tasks that are performed in the test environment before committed to the live environment.
The Java versions are JRE 6u45 and JRE8u112, both on a Windows 7 x64 platform.
At first, I had installed JRE 6, installed/ran the application, verified it worked, then installed JRE 8 (test, which if we can properly test it, live will be upgraded to this version as well), ran the test application, it worked. Great. So what's the problem? When I launch the JRE 6 application, it actually calls the JRE 8 environment and fails to launch. After trying to modify the environmental variables PATH and messed around with JAVA_HOME and various Java version keys to work with in scripting files, I gave up in getting it to work through this method.
I uninstalled both versions, reinstalled them, copied the installation folders, uninstalled both, then removed all traces from the registry.
I put the JRE 6 folder into C:\Program Files\Java\jre6\
I create a shortcut to run the application, then give it a try. It works! Great. I do the same thing for the JRE 8 folder, it works. I jump for joy and tell my colleague that I've done it. I go to show him, and nope. Java 6 webstart (javaws.exe) is the proper version. javaw.exe is running from the JRE8 FOLDER!!!
I check the registry - no trace. I'm puzzled. I take a look at the original shortcut the application makes and it references the Local AppData folder. Okay - I go in there and delete every Sun and Oracle folder from every sub folder in my profile. "Ah ha!" I says, "I found you sneaky config files and you're gone!". Nope. Java just wanted to watch me suffer some more.
Basically, when I launch the javaws from the JRE6 folder, it doesn't launch the JRE6 javaw.exe, it launches the JRE 8 version instead. My question is - where in the world does Java look for, and store, the information on where to load the environment from?
Thanks in advance!
You do realise that you can run code compiled for an old JVM on a newer JVM, so you may not have a problem. You also know about the -target and -source options for the javac tool, which allow you to compile or run code compatible with older versions?
Do you mean that the vendor uses old versions of Java®, or is it your costumer? It is if the customer uses old versions that you will have problems.
I would suggest you install the different versions in the usual fashion. I would suggest the latest version of Java8, which I think is 8u131. If you have installation downloads for Java6 and Java8, install them, but be sure to install JDKs not JREs. The JRE is a small part of the JDK. As you install each JDK, you will see a location it is being installed into. Record that location and append “;\bin” to it, and you now have a path to the executable. Edit your system PATH variable by adding one of those to its beginning, and try the following instructions at a new command window:-
Open another command window and give it the following instruction (if I get it wrong, somebody will doubtless tell you. I am making some assumptions about your installation location):-
set PATH="C:\Program Files\Java\jdk1.6.0_45\bin;%PATH%"
and repeat the two instructions I told you earlier. Now you can use that command line to compile and execute code for Java6.
Check the update history for Java6 carefully; some versions contain security vulnerabilities, so make sure to use a newer update.
When I did have them installed, the version came back as JRE 6, but it didn't make a difference. So once I can figure out where that path is getting stored so I can clear it, everything will be fine.
The file in question is located at c:\users\UserName\AppData\LocalNow\Sun\Java\Deployment\deployment.properties
Delete that file, and JRE6 works, though it redownloads, so all local data would be erased each time. That's okay, though, as I can work around that.
Hopefully someone finds this information useful. Cheers!
Rob Spoor wrote:It may work, but you may have made it impossible to uninstall Java (to be honest, I have no idea). That file was there for a reason, and you shouldn't just have removed it.
There's no installation of Java needed for this to work, so it's not impossible to uninstall it. In fact, during some testing, I had to install Java 8 and uninstalled it without issue, so I'm really not sure what you're talking about. How can you say I made it impossible and then in parenthesis that you honestly don't know? The file is moved to a another folder (same with the rest of the contents of that folder) and replaced with the other apps data, and is cycled out. Maybe if the vendor didn't use antiquated versions of Java and knew how to make sure both of their instances played nicely together, this wouldn't have been an issue.
It works perfectly as intended, and yes, Java can be uninstalled, it can also be installed, and with this solution, no other instances of Java will mess with this method.
I'll never understand the mentality of you java folks with the way you respond to others who aren't in your "esoteric group of coders". It's always some condescending response without admitting that Java is just a horrible environment.
Anyway, cheers. I won't be back =)
Harold Peterson wrote:I'll never understand the mentality of you java folks with the way you respond to others who aren't in your "esoteric group of coders". It's always some condescending response without admitting that Java is just a horrible environment.
I would have given the same warning to anybody - including myself. There was no condescending intent.