I’m gonna share how to keep an older version of the JDK and JRE for compiling/debugging/running legacy code and running Ant, but still run Eclipse on JDK 6. Of course, coding for the new JDK is also possible.

JDK 6 Installation and Path variables
First you’ll have to download and install JDK 6 from Sun’s website.
Install it like usual but keep the old JDK (meaning don’t uninstall the old one). Of course, install the new
JDK in a different directory from the old one. Next, modify your path and JAVA_HOME variables. To change these in Windows XP, hit Windows+Pause key on your keyboard and navigate to Avanced tab.

Click on the Environment Variables button to bring up a dialog. Locate and change the list of variables under the System Variables for a system-wide change.

You’ll need to reboot for it to take effect. Alternately, you can set it via the command-prompt by typing

Set Path=C:\Program Files\Java\j2re1.4.2_06\bin;C:\j2sdk1.4.2_06\bin;….(your other path variables…[Enter]

Set JAVA_HOME=C:\Program Files\Java\jdk1.6.0[Enter]

You’ll need to type the complete Path and JAVA_HOME variables. If you have multiple JRE/JDK paths set, the first one to appear in the path variable will take effect meaning by default, all Java programs will use that VM. So generally, it’s advisable to have the new JDK’s path in your Path variable. Set your JAVA_HOME variable accordingly. Note: It is perfectly fine to have your system run the old JDK by default. As a matter of fact, JDK 1.4 is default on my laptop.

Run Eclipse 3.2 on the new JDK
If you chose to run JDK 1.4 by default (by setting it in your system-wide Path variable), you’ll notice that Eclipse will use the old VM to run. This is not desirable because it runs much faster on the new JDK 6, no doubt due to VM performance optimizations (bravo to the folks at Sun!). To force Eclipse to run on the JDK, locate (or create) a shortcut to run Eclipse. Add the following arguments to -vm [JDK path to javaw.exe].

Here’s an example of my Eclipse shortcut arguments:

C:\eclipse32\eclipse.exe -vm “C:\Program Files\Java\jre1.6.0\bin\javaw.exe” -vmargs -Xms128M -Xmx512M -XX:PermSize=64M -XX:MaxPermSize=128M

Note that the -vmargs, if any, must come after the -vm flag because running the -vmargs flag first will force Eclipse to use the default system JDK (which is an older JDK).

To check if Eclipse is running on the new JDK, launch it using the shortcut. Go to Help->About->Configuration Details. The -vm flag should point to the new JDK’s directory.

Force Eclipse to set its Compiler compliance to an older JDK

To set the default compiler compliance for Eclipse, navigate to Windows->Preference -> Java -> Compiler. Set the compiler compliance accordingly.

To set project specific compiler compliance, right-click on a Java project folder and click on Properties then navigate to Java Compiler. Set the compiler compliance accordingly.

Force Ant in Eclipse to run using an older JDK

It’s no use if Ant chooses to use a new JDK to compile code. In some cases, Ant might even refuse to run, complaining about the wrong JDK being used (a message stating java.lang.UnsupportedClassVersionError: com/sun/tools/javac/Main (Unsupported major.minor version 49.0 when running an Ant script). To force Ant to use a specific JDK, navigate to Windows -> Preference and expand the Ant -> Runtime tree in Eclipse.

Change the tools.jar library to the specific JDK you want Ant to run on. That’s it! Once all these steps are completed, you should be able to code and deploy for both JDK versions.

In an ideal world, everyone would upgrade to the latest and greatest JDK when a new one is available. In the real world, people use ‘old’ JDKs until it is absolutely necessary to change. It’s understandable of course, upgrading usually involves cost, usually because of the need to purchase new application servers, IDEs, etc. Not to mention cost related to business risk if the system fails. It also involves a fair amount of risk, considering a new recompile is needed, old binaries might break, etc. That being said, I still think it can be beneficial, sometimes even advisable to use the latest and greatest JDK whenever possible, taking into account the risks involved; rather than a blanket “No” to all upgrades (or a “Yes, let’s upgrade”) mentality.