Onward and Upward: Porting Apps to Higher JDK Versions : Page 2
Porting an existing Java-based application to a new JDK version is not as easy as many assume. Learn a comprehensive, systematic approach that can ensure a smooth process.
by Rahul Kumar Gupta
Sep 28, 2004
Page 2 of 4
Why Port in the First Place?
What are the reasons or external events that necessitate the porting process? One good reason for porting is to take advantage of the new features and improved functionality of a newer JDK, but you still must determine whether that's a real business requirement. If none of your business applications require the new features the newer JDK version introduces, then spending the time and money to port your existing application may not be a good idea. On the other hand, if you are in the business of developing software products, then it is mandatory to constantly upgrade and support the latest functionality on the market in order to give customers value for their money.
The following are some of the scenarios in which one should port an application or product:
When an existing application/product stops running on the targeted JDK [The changes introduced in the JDK, which are mandatory for implementation, can cause this (e.g., changes in the existing interfaces, changes in exception handling, introduction of new keywords such as assert in JDK 1.4, etc.)]
When you want to improve the performance of your existing application/product with the features introduced in the targeted JDK
When you want to remove the application's dependency on third-party products/APIs, which are now introduced as features of the targeted JDK (e.g., using of logging API instead of Log4j)
When a new feature replaces an old one and the new feature will be used in all forthcoming releases
When you want to use the new JDK compiler, and you want the program to compile cleanly
When you are in the business of product development or producing APIs, then upgrading is a business need for client requirements as well as for competitive edge
You may be thinking: if Java truly delivers "Write Once, Run Anywhere" (WORA) functionality, porting applications between JDKs should be so trivial as to make this article moot. True, but WORA is not always the reality. Sure, when you move from a Windows to a Unix platform or vice-versa, your JDK version remains the same. However, you have to keep some key points in mind while writing the code, including:
Naming conventions—Unix is case sensitive.
Use of appropriate separators (File.pathSeparator and File.separator)—Unix uses '/' and ':' as file and path separators, while Windows uses "\" and ';', respectively.
AWT GUI components—They need special attention. Nowadays, it is advised to use swings.
Threading model—In this arena, Java's WORA falls flat on its face. Making threading truly platform independent is a nightmare for programmers. For example, programmers are advised to break up thread-processing code written in the run method into smaller chunks and, if necessary, to call yield() at the end of a loop iteration. In a nutshell, they must keep the pre-emptive and co-operative models in mind while writing this code (Read this article for more information: An Introduction to Java Thread Programming)
Internationalization—Character sets are different in Unix and Windows.
Proper path usage—Avoid using absolute paths, try to use relative paths instead. If that's not possible, try to fetch from properties files.
So, with all these factors to consider, you very well may run into problems when you try to run or compile your existing application on a newer JDK version.