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
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?
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".
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.
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.
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.