Reply

Eclipse: Per-Project JRE Libraries

At 11:28 PM on Mar 16, 2005, R.J. Lorimer wrote:

Runtime environments change often. A lot of times it is possible that, as a developer, you have a program that builds and is tested with Java 1.4 (or perhaps Java 5 because you are using TestNG ). At the same time, you may be running in an environment at a different level - say, Java 1.3. For a real-world example, the application I am currently working on has a 1.3 server, and a Java 1.4 client installation. It can be important to able to micro-manage what happens at each stage of your application development in Java.

So, how can you manage these concerns when working with Eclipse? Well, the first thing to understand are the three realms that have to be managed - those are 1.) the compiler compliance used, 2.) the runtime libraries compiled against, and 3.) the runtime environment used for execution. It's important to understand these three different aspects of managing your application's runtime, because Eclipse manages each in a different way. Why am I going to all the trouble to describe each? Well, I personally find that Eclipse's way of managing JREs is rather unintuitive. Don't get me wrong, I like Eclipse, and the JRE support is VERY powerful - it just so happens that it feels a bit littered throughout the IDE. Most people seem to either think that your applications run on the JRE that Eclipse was started with, or they run with the default selected JRE in the installed JREs dialog (which I will be showing shortly). This is simply not always the case, however. As I go through the various configurations in Eclipse, I will be supplying screenshots. These screenshots are from Eclipse 3.1 M5.

Managing Compiler Compliance

Eclipse ships with a special class file compiler, called the Eclipse JDT ( J ava D evelopment T ools) compiler. The JDT compiler is 100% compatible for the Java specifications, and allows Eclipse to do many neat things, such as incremental compiling of class files. Perhaps due to the integrated nature of the compiler, Eclipse's compiler settings are quite detailed. Compiler compliance settings can be set at a per-workspace level, as well as at a per-project level. To set the compiler compliance for the workspace, go to: Window->Preferences->Java[+]->Compiler[select] . Here is what the preferences page for the workspace-wide compiler settings looks like:

If you want to set the compiler compliance for a particular project, right click on your project and go to Properties->Java Compiler[select] . Once there, the preference page is largely the same:

Targeting The Right Runtime Libraries

Being able to ensure you don't use generics/var-args/enumerations in your Java 1.4 application is a good thing, and you can ensure that by setting your compiler up right - but it is also very important you don't use a library that didn't exist in a prior release (don't try to use regular expressions in Java 1.3 for instance). Changing the compiler compliance won't help detect these problems; instead, you must ensure that you don't have these classes on your classpath when you are writing your code. To change the JRE library your code is compiled against, you can start by selecting a default JRE. Goto Window->Preferences->Java[+]->Installed JREs[select] and select the appropriate JRE. Your JRE isn't there? Well, while you're there, insert the JREs you need. By the way - way-back-when I posted on my blog about how you can use a JDK as your JRE, and instantly get free source browsing - check out this link for more: Coffee-Bytes.com - Eclipse Tips and Tricks: JDK Source Browsing . Here is what the installed JRE preferences page looks:

Once you have a default JRE selected, it will be used for all projects. If some of your projects require different compliance levels (as is my case), you can, once again, alternatively specify these settings for an individual project. Go to Properties->Java Build Path[select]->Libraries Tab[select] . Once there, you can remove the default JRE System Library, and then click 'Add Library'. Select 'JRE System Library' and click next, select 'Alternate JRE' and select your project's appropriate JRE out of the list, and then click 'Finish'. Here is a set of screenshots for that process:

Running your Code in the Right JVM

Ok, so now the compilation process is nailed-down. You're not compiling for the wrong JRE, and you're not compiling against the wrong libraries. The only thing that is left now, is to ensure you aren't running your code for testing/debugging under the wrong JVM. Thankfully, this setting is largely the same as the compile-time JRE setting. Assuming you have a runtime-context for your application's bootstrap method (your main method), you can simply go to the 'JRE' tab, and change the JRE to an alternate one (much like you did for the project). The default on this page should be the runtime JRE of the project containing the class to be executed - so in many cases this should require little to no work to keep correct. Here is a screenshot:

Just so you know, this information will come in very handy in the near future. Notice how a lot of my screenshots have j2sdk1.5.0 + Compiler in them? Well, I'm planning to show a little bit about some cool (and little known) Java 5 features out there.

Until next time,

R.J. Lorimer
rj -at- javalobby.org
http://www.coffee-bytes.com