How Do I Port My Application?
Once you have identified the porting tasks that need to be performed, as well as their priorities, make an action plan to execute the porting process. Testing plays a very important role in this execution. Create base line results or use existing base line results for unit, system, performance, and acceptance testing of your current system for each platform it supports. Figure 3
shows a porting process flow diagram.
Before starting the porting process, take the following steps:
- Prepare a list of the following changes:
- Incompatibilities introduced in Java API and Sun API for targeted JDK version
- Deprecated APIs
- Suggested improvements
- Newly added features
Try to estimate the number of occurrences of each identified change in the entire application source code (i.e., what is the approximate number of places you have to make changes corresponding to each JDK change introduced). Also estimate the time required for each change. Table 1 offers a sample template for capturing these details.
|Table 1. Template for Capturing Change Details|
- Prepare baseline results.
Consider a scenario in which a CRM product supports the following:
- ATG and BEA WebLogic application servers
- Windows, Linux, and Solaris operating systems (OSs)
- JDK 1.3
The product needs to be ported to JDK 1.4. As discussed previously, comparing the test results on the ported platform with the original (baseline) test results is crucial. So the baseline results and actual results must be captured. Table 2 offers a template for capturing test results.
|Table 2. Template for Capturing Test Results|
Capture the test results for each of the supported OSs (Windows, Linux, and Solaris) separately. If all the baseline results match the new test results of the ported application, then your porting process is almost complete.
Another advisable practice is performing Java compatibility tests as per your requirements [e.g., Pure Java Check and J2EE CTS (Compatibility Test Suite)]. Such compatibility ensures that implementations of Java technology meet Java specifications. Table 3 presents some of the changes that you might have to perform while porting an application from JDK 1.3 to JDK 1.4.
The areas where you'll notice the majority of changes across different JDK versions are security, AWT, swings, I/O, exception handling, RMI/CORBA, and the collection API.
A Systematic Approach Covers All the Bases
The process and strategy this article describes may not be the only way to handle JDK porting activities, but from my experience with these types of project, it provides a comprehensive, systematic approach that can ensure a smooth process.
Credits: The author wishes to thank his project manager Atul Jain and his colleague Saurabh Bhatnagar for their valuable contributions as reviewers for this article.