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.
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:
Looking at that page, the list of major areas of change in moving from JDK 1.3 to JDK 1.4 covers the following:
XML Processing, New I/O APIs, Security, Java 2D technology, Image I/O Framework , Java Print Service, AWT, Swing, Drag and Drop, Logging API, Java Web Start Product, Long-term Persistence of JavaBeans Components, JDBC 3.0 API, Assertion Facility, Preferences API, Chained Exception Facility, Endorsed Standards Override Mechanism, Java Virtual Machines, Performance, Networking Support, Including IPv6, RMI, Serialization, Java Naming and Directory Interface (JNDI), CORBA, Java IDL, and RMI-IIOP, Java Platform Debugger Architecture, Internationalization, Java Plug-in Product, Collections Framework, Accessibility, Regular Expressions, Math, Reflection, Java Native Interface, Tools and Utilities.
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.
To view the current JRE level, on the main menu, do the following:
- Select Windows > Preferences
<< A window opens showing the Preferences dialog
- 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 firstname.lastname@example.org.