Different versions of Java (JDK 1.3, JDK 1.4 and JDK 1.5) have very different capabilities. They also have very different effects on how you run your Java applications. With IBM's WebSphere Development Studio Client (WDSC) toolset you have the ability to selectively set a Java version for your development environment. That allows you to develop applications compatible with different Java runtime environments.

By submitting your personal information, you agree to receive emails regarding relevant products and special offers from TechTarget and its partners. You also agree that your personal information may be transferred and processed in the United States, and that you have read and agree to the Terms of Use and the Privacy Policy.

In this article we'll look at the options and issues with setting different Java versions in the current version of IBM's WDSC toolset: 5.1.2.

Are Java versions really different from each other? If you're new to Java, you might wonder how different the Java versions are. Coming from an iSeries background, how different is V5R2 RPG from VRr3 RPG? Not very. Older languages such as RPG, COBOL and Visual Basic evolve relatively slowly. Java, on the other hand, evolves faster than any other language today. Changing Java versions may be similar to changing from OS/400 V4R1 to OS/400 V5R1 in the potential impact on development and runtime environments. You don't make those changes without careful planning, training and testing.

In fact, to better reflect the significance of these changes, Sun's adopting a new naming convention. Instead of going from JDK 1.4 to JDK 1.5, they are now also referring to JDK 1.5 as JDK 5.0.

Comparing JDK 1.3 to JDK 1.4 As a developer, I focus on the Java Development Kit (JDK) that is a combination of the Java Runtime Environment (JRE) and the Java Development tools (compilers and utilities). The JRE in a JDK is based on Java 2 Standard Edition (J2SE). Below is a URL from Sun that summarizes the changes from JDK 1.3 to JDK 1.4:

The list of what HASN'T changed would be shorter. This list DOESN'T include all the Java 2 Enterprise Edition (J2EE) changes for Web application servers such as JBoss, WebSphere Express and Apache Tomcat. Those versions also change significantly between releases. For instance, Java Server Pages (JSP) changed radically from J2EE 1.3 to J2EE 1.4 with the addition of Expression Language changing how Web developers build Web pages.

I've also occasionally found small differences between Sun JREs and IBM JREs for the same Java version. That can create additional problems for a developer.

What about the new JDK 1.5 (or as Sun says, JDK 5.0)? While it's available from Sun now, WDSC and Eclipse are not designed to work with it. I haven't tried loading it in WDSC, but I wouldn't expect it to work. There are again many changes from JDK 1.4, even some in the virtual machine that may create incompatibilities with WDSC.

Can you mix Java versions? You cannot mix Java versions easily. You have a single JRE that is in effect when you compile or run your applications at any point in time. IF you have the wrong version of other frameworks (for instance a XERCES.jar for XML parsing) that is higher in your project classpath (Java's equivalent of a library list), you can hit a variety of runtime errors. By comparison, on OS/400 IBM's install system prevents you from mixing different versions of OS/400 and other system programs (SDA, RPG, etc).

Types of problems I've hit when accidentally mixing the wrong version of a framework with a JRE on a project include the following:

Class not found error A class you need is missing in one version of Java when it was available in another

Symbolic link error A class fails to load in the Java Virtual Machine (JVM) because its implementation isn't found at runtime even though it compiled correctly

Class doesn't implement an interface error For example, running a JRE 1.4 application for regular expressions in JRE 1.3 runtime caused an error: "String doesn't implement CharSequence". The implementation of String in JRE 1.3 didn't support the CharSequence interface and couldn't run with the RegExp package in JRE 1.4.

Or worse, it runs but the behavior is different This may be a real problem. The application runs without error BUT the behavior of Java has changed between the JRE levels. The challenge here is finding the error to begin with. In many cases, your application ran without error but the result isn't what you expected.

How do you change a Java version in WDSC? The current version of WDSC (5.1.2) ships with the default JRE as 1.3. You can also use one of the available installed JREs for Version 1.4.

The Java version (JRE level) is set in two places in WDSC: the workspace level and the project level. By default, all projects use the workspace settings for the JRE for compiling and running applications, including the Java scrapbook pages.

Select Java > Installed JREs << The list of installed JREs is shown below with the default one (Eclipse) checked to show it is the current JRE used in the workspace

To set a different JRE level for your workspace, do the following:

Set the JRE to use for the workspace In the Preferences dialog above, you can check a different JRE type than the default Eclipse one at the top. Here, I've checked a JRE for the WebSphere V5.1 test environment. This will be used as the JRE to compile and run applications in the workspace at JRE 1.4 level.

Set Java compiler compliance level for the workspace Select the Java > Compiler > Compliance and Classfiles option in the Preferences dialog << The compliance setting page opens showing the current JRE compliance level By default, this is 1.3. In the diagram below, you can see I've selected the other option, 1.4.

Update the Java Classpath variables if needed In the preferences dialog, Select Java > Classpath Variables By default, these variables are normally pointing to JRE 1.3 level jar files. You need to review these and see if any need to be edited to point to JRE 1.4 level files After clicking OK, you will get a message telling you the workspace will be rebuilt. Click OK and let WDSC recompile the workspace. If you have a lot of projects open, this can take a while.

Update the project build path to reference compliant classes and jar files Now, go edit the build path, if needed, on your project Select your project in the Navigator view, right button menu and click on Properties << the Project Properties page opens Select Java Build path > Libraries << The Libraries page opens listing the classpath variables currently in use
The diagram below shows the classpath variables I have set for a WebFacing project

Rebuild the project Having updated the classpath and the workspace, you need to rebuild the project In the navigator view, select the project On the main menu, Select Project > Rebuild project The project is now recompiled using the JRE settings for the workspace and the classpath variables you've set. This may take awhile.

Test the application Having rebuilt your workspace and project for JRE 1.4, you need to test your application by running it in the scrapbook or running the Java class directly from the Run menu. Either way, be sure to check the results of the test application are what you expect given the change in JRE level.

What's the impact of changing a JRE level in WDSC?

The workspace is recompiled

The project Java build path probably needs to be updated

The project will need to be rebuilt

You'll need to test your Java applications to see the impact of the update.

In my case, I wanted to use a new feature of JDK 1.4, Java Regular Expressions for parsing Strings. It's part of a new package, java.util.regex. While there are plenty of good third-party Regular Expressions packages that run in JDK 1.3 (see Jakarta Commons REGEX project), I wanted to try out the standard one included with 1.4. In hindsight, it was more work than it was worth in WDSC, since most of my other projects are written to JRE 1.3 and have compile errors in 1.4. Next time I'll use an Apache regular expression jar file, which is easy to add to a JRE 1.3 project (about one minute's work).

Having moved my workspace to 1.4, I tested the Java Regular Expression functions both in the Java scrapbook and some Java classes. The regular expression functions really cut the work down to parse character streams.

One feature of WDSC that doesn't work is the ability to set a compliance level for a project DIFFERENT than the compliance level for the WDSC workspace. Having set my workspace to JRE 1.4, I set my project properties for Java compiler > compliance level to JRE 1.3. After rebuilding my project and retesting my Java classes and scrapbook with the Regular Expression features, they should have generated errors. They didn't. If IBM has a fix for this, I'm not aware of it.

Recommendations on managing Java versions in WDSC As a Java developer in WDSC, you'll need to be aware of the JRE level (and corresponding Java features) you want to use in your projects and your runtime environments. If you're new to Java, I recommend you stick with the default JRE settings if possible or get some experienced help to think through the specific issues you'll face switching to a different JRE level.

In the future, I'd like to see a version of WDSC that does support project overrides for JRE levels and allows you to pull in more recent versions of the JDK than those shipped with WDSC.

---------------------------------------

About the author: Jim Mason works at
ebt-now, an iSeries Web integration company, providing QuickWebServices for iSeries customers: Web planning, WebSphere, WebFacing, Web development, Web networking, Web support, Web security and training services. Jim is creating a self-study course for RPG programmers that teaches "hands-on" rapid visual development with WDSC for all types of iSeries and e-business applications without the need to become a Java expert. The course will be published by Rochester Initiative. You can reach Jim at
jemason@ebt-now.com.

0 comments

E-Mail

Username / Password

Password

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy