Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I think this has to be a common issue, but I haven't found any clear solution.

We have several products that are accessed via a browser (IE 7) with JRE version 1.5.

We now need to be able to support another application using JRE 1.6.

I thought that one solution would be to install Firefox on the client and set 1.6 to only work with Mozilla-type browsers, but I've found that this doesn't actually work. I still got 1.6 in IE, which caused issues with the older applications.

Is there a way to separate which JRE is used by browser? Batch scripts or registry hacks would probably be fine.

Update - April 6th, 2011:

We have one application that insists on using IBM JRE 1.5 v9. If we try to run it with any other JRE version then it will simply prompt a download of the JRE from the server. Maybe it would work with JRE 1.6, however, it doesn't recognise any other version than the one it wants to use. The product we are using is ITM (IBM Tivoli Monitoring). I have also seen similar behaviour with other COTS products in the past e.g. Ciscoworks, which used to only work with JRE 1.4.2_06. Any other version and it prompts for a plugin install...

So my question is not about compatibility of one Java version with another. My question is about how to support applications that have to work with different version of JRE, from the same client

Oh, and I can't use anything that requires a user to enable/disable plugins as required, because this has to run on a restricted client system (on which the user will have very limited user level privileges). The current setup has application icons (Internet Explorer with a URL argument) that they select from the desktop.

share|improve this question
1  
How much control do you have over these products? Could a situation like the one jzd mentioned in a comment be applicable to you? –  Pops Apr 5 '11 at 17:29
add comment

migrated from serverfault.com Apr 4 '11 at 14:08

This question came from our site for professional system and network administrators.

3 Answers

Java should be backwards compatible, so the program compiled in 1.5 should run fine in 1.6. In fact there is not much that is different syntax wise between the two and 1.5 is getting to be really old. I would suggest testing your 1.5 products on 1.6 and seeing if they operate correctly.

share|improve this answer
    
You're right, it should be, but I've run into cases where it's not. –  Pops Apr 5 '11 at 17:21
    
Also, the OP already tried testing the 1.5 products in 1.6 and they failed: "I still got 1.6 in IE, which caused issues with the older applications." –  Pops Apr 5 '11 at 17:26
    
@LordTorg, agreed, but testing the application allows you to determine if this is the case or not. I was told that an application would only work on Java 1.4. Which I found only to be true for 1 small admin feature. This allowed all the non-admins to be bumped up to 1.6 which was required by another app. –  jzd Apr 5 '11 at 17:26
    
Hm, good point, I didn't think the OP had access to the products themselves. I'll ask in a comment. –  Pops Apr 5 '11 at 17:28
    
@LordTorg, yes, I am running on a little speculation since the question is not perfect. –  jzd Apr 5 '11 at 17:31
show 3 more comments

In Mozilla Firefox at the add-ons page you can disable/enable plugins. Install the necessary JREs. Then create separate Firefox profiles. And in each profile enable/disable the specific JREs as required.

share|improve this answer
add comment

You can have multiple versions of Java installed, but I don't know how you force the browser to use one or the other for specific applications. Perhaps it'll do it automatically somehow depending on how the application is launched?

Edit: another Stack Overflow link covering it to some extent is Multiple Java versions running concurrently under Windows.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.