JRE 6 and 7 side-by-side with JRE 6 as default (Win 7)

Question

For a migration project to migrate from Java 6 to Java 7 runtime on Windows 7, we are looking to get the following situation:

• Both JRE 6 and JRE 7 are installed on the machine
• JRE 6 is set as the default
• JRE 7 will be explicitly requested by applets and webstart applications that require it.

We found lots of solutions that use the path to achieve a situation like this, but we are looking for a way to keep the default path (using the java.exe in C:\Windows\System). Changing the registry key \HKLM\SOFTWARE\Wow6432\JavaSoft\Java Runtime Environment\CurrentVersion to 1.6 does not work unfortunately.

Does anybody have experience with a setup like this?

Edit: I get a lot of questions WHY we want this. I can discuss all the ins and outs, but please take it from me that we discussed all possible scenario's and this is the one that impacts our business the least. There are more than 10K systems (laptop + desktop) involved and lots of different Applets, webstart applications and standalone client applications involved.

Answer 1

I had a problem that was nearly the same as yours, I wanted to use jre 6 to run an old version of sgd (sun secure global desktop). My walkaround for this :

• Get firefox portable
• about:config --> plugin.scan.plid.all = false (don't know if it's necessary)
• Add jre portable version 6 to the folder (plugins)
• Go to the Java Control Panel (in Windows Control Panel) --> Java tab --> View.. (Visualiser in french) --> Uncheck 1.7

May be just the last step will work for you...

Hope this will help someone.

Answer 2

I wrote a tool to be able to run WebStart on JRE6 and JRE7 side by side. You can download the tool here.

Answer 3

Unfortunately the answer for Applets and web start is that this is not possible (anymore). As can be found in the JRE installer options page of Oracle, the latest JRE is chosen by the browser plugin by default:

Beginning in Java SE 6 update 10 release, the latest JRE software will be registered with all browsers. This ensures that applets will run on the latest and most secure version of the JRE software.

Some solutions can be found that suggest changing several registry keys, but these only work for versions prior to 1.6.0 update 10. As soon you install this or a newer version, those registry keys are ignored.

We are still awaiting a formal response from Oracle, but we do not expect a different outcome.

Answer 4

I think that the answer is that there probably isn't a way to do that which is going to work for all of your existing menagerie of in-house and 3rd-party applications ... and their various ways of locating their Java platform.

And if you get something that works "most of the time" then there is a good chance that the breakage in the other cases will be worse than if you had taken a more aggressive approach to conversion.

The root problem here is in-house and 3rd-party stuff making unwarranted (and probably unnecessary) assumptions about the Java platform they are running on. If the application can't be fixed to get it to work on Java 7, it probably should be ditched ... or quarantined in a heavily fire-walled virtual machine or something. Java 6 has been EOL'ed. So unless your organization is prepared to pay big bucks for support from Oracle you won't get any more security patches. IMO, that is good enough reason to boot it out of your supported / allowed COEs ... whether the users like it or not.

It is all very well to say that there is politics in the problem. But if push comes to shove, >>you<< guys will get the blame if your "gently, gently" approach fails technically and you get security problems due to running unpatched / unpatchable Java installations.