Question

I’m in the process of reviewing a code base (~20K LOC) and trying to determine how to migrating it from 1.4.2 to 5. Obviously, it’s not an overnight project and the suggestion which I have received is to write new code against Java 5 and migrate the old code in a piece-meal fashion. Also, I’m no expert in the new features in Java 5 (i.e. I know of them, but have never written any for production use).

My questions:

1. What features of Java 5 are typically used in production code? (i.e. generics, auto-boxing, etc.) Are there features to be avoided / not considered to be best-practices?

2. What are the best refactoring strategies which I can use migrate a code base of this size? (i.e. make changes to classes one at a time only when a class is edited, etc.) Objective – reduce risk on the code base. Limitation – resources to do refactoring.

Any advice is appreciated – thanks in advance.

UPDATE – a year too late, but better late than never? =)

Thank you for all of the comments – lots of great points of view. In the life of a software developer, there’s always going to be the projects you strive to finish but never get around to because of something more ‘urgent’.

With respect to the use of Java 5 (at that time), it was something which was required in the client’s production environment, so that was why we did not use Java 6.

I found that the stronger typing for collections, enums and unboxing of primitives were the features I tend to apply the most, both to old and new code. The refactoring was fairly straight-forward, but code comprehension improved significantly and standards became easier to enforce. The ones I had the most trouble with was the generics; I think it’s a concept which I still haven’t had a chance to fully grasp and appreciate yet, so it was difficult for me to find previous cases where the application of generics was appropriate.

Thanks again to everyone who contributed to this thread and apologies for the late follow up.

Answer 1

Java 5 is almost completely backwards compatible with Java 4. Typically, the only change you must make when you migrate is to rename any usages of the new enum keyword in the Java 4 code.

The full list of potential compatibility problems is listed here:

http://java.sun.com/j2se/1.5.0/compatibility.html

The only other one that I’ve run into in practice is related to the change in the JAXP implementation. In our case, it simply meant removing xerces.jar from the classpath.

As far as refactoring goes, I think that migrating your collection classes to use the new strongly-typed generic versions and removing unnecessary casting is a good idea. But as another poster pointed out, changing to generic collections tends to work best if you work in vertical slices. Otherwise, you end up having to add casting to the code to make the generic types compatible with the non-generic types.

Another feature I like to use when I’m migrating code is the @Override annotation. It helps to catch inheritance problems when you’re refactoring code.

http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Override.html

The new concurrency library is very useful if your code uses threading. For example, you may be able to replace home-grown thread pools with a ThreadPoolExecutor.

http://java.sun.com/j2se/1.5.0/docs/relnotes/features.html#concurrency

I would definitely take the approach of updating the code as you change it during normal maintenance. Other than the compatibility issues, I don’t think there is a compelling reason to use the new Java 5 features unless you’re already changing the code for other reasons.