Different versions of Java SDK - can they Co-exist on same machine?

[Subir Mukherjee]

Hi:

I am working on a production environment that is almost legacy in nature - working off JDK 1.3.x. This legacy application talks to an outside 3rd party application.
Recently, there have been some upgrades at the 3rd party site and they now require us to talk to ther application using their latest API which is SDK 1.6.x based.
At my end, I have issues in upgrading SDK on the machine with legacy application for fear of breaking existing code (example: some method calls that currently work may be deprecated in the new SDK). Since this is a LIVE site - I cannot afford any downtime!

My question is whether I could have 2 versions of Java co-exist on the same machine. Is something likely to break at the JVM level, on the 1.3.x version if I install the latest SDK? Ideally, I would like the older JDK 1.3.x to continue to service my legacy application. While the newer SDK 1.6.x could service the new objects that I can use to communicate with the 3rd party.

FYI, I am in a Windows environment (Server 2003). Application server is Sybase EAServer Version 4.2

Look forward to your response.

Thanks for your time.
Subm

[Campbell Ritchie]

You can have as many Java installations as you like, as long as you remember to change the PATH every time you change JVM. I can't remember what you do in DOS/Windows, but it is something like writing

set PATH = C:\Program Files\java\jdk1.3.1_03\bin;%PATH%

You may have to put quote marks "" round that instruction because it contains whitespace.

[Subir Mukherjee]

Hi:

Thanks.

This is a web based application that I have. The web objects are deployed as JAR files onto the App server. The 3rd party's web object is also a JAR File. So in the servers's environment variables, if I have both the paths - "C:\Program Files\java\jdk1.3.1_03\bin" and "C:\Program Files\java\1.6.0_16\bin" separated by ";" will the older and newer JARs pick up the relevant SDK that applies to each automatically?

Thank you
Subm

[Vijitha Kumara]

Subir Mukherjee wrote:.... So in the servers's environment variables, if I have both the paths - "C:\Program Files\java\jdk1.3.1_03\bin" and "C:\Program Files\java\1.6.0_16\bin" separated by ";" will the older and newer JARs pick up the relevant SDK that applies to each automatically?

No. Only one Java environment is applied (whichever is available during the application server startup & that is configured for the application server to use). If you have few installations in "Path" environment variable, and say when you compile java file the first one in the list will be taken. You can test this by "java -version".

[Subir Mukherjee]

Thank you All. I guess this leaves with me with only 1 choice - to separate out the applications into legacy part on 1 machine and have an internal redirect to a machine with newer SDK in order to meet my 3rd party's requirement.

Thank you
Subm

[Campbell Ritchie]

Why do you need to run the old parts on an old machine? You may need some refactoring for a new machine, but the JDK6 will happily run 1.3 code.
I suspect boxing and un-boxing will be the most difficult features to refactor.

[Subir Mukherjee]

Thanks Ritchie. It would certainly reduce time and work if the entire application could run off a single box. I was aware of the backward compatibility of newer releases of the JDK but was not entirely confident as to how deprecated method calls would be handled by the newer JDK. That was my original concern.

Thank uou
Subir

[Campbell Ritchie]

Which deprecated methods are you using? There are some eg Thread.stop() which you ought not use at all. A lot of the other deprecated methods will run with warnings only.