A trial port to JDK1.5

2 AM January 14, 2005

I did a trial port of our application from JDK1.4 to JDK1.5, using Eclipse 3.1M4. The results were encouraging, but we won't be moving across right away.

To give you some idea of the size of our project, it is comprised of two sub-projects: the first is a bunch of utility and helper classes that runs to about 10k lines, and the other is the main application at about 40k lines. We make good use of open source libraries and frameworks, including Spring, Hibernate, Apache Axis and Jakarta Commons.

Doing a port

I first recompiled the utility project under JDK 1.5, coming up with 28 warnings and no errors. A fair number of the warnings were to do with not having a serialVersionUID on a serializable class. I gave up fixing those when it wanted me to put a serialVersionUID in an anonymous subclass of javax.swing.AbstractAction. (As an aside, Eclipse lets you turn off a warning completely, but it would be nice if I could have turned off this warning for subclasses of Swing classes.)

Most of the rest of the warnings were fixed by simply adding type parameters to collection types; for example, List might become List<String>. I also removed unneeded casts, and used the new for-loop syntax wherever appropriate. This is a fairly routine, mechanical process, and I was done in about two hours.

I then loaded up the bigger project and promptly received 31 errors and 400 or so warnings.

The errors were because we use the commons-lang Enum class, and enum is a reserved word in JDK 1.5. The fix was to convert to the new Java enumeration types. This was straight forward, mostly because the JDK1.5 and commons-lang enums are both based on Joshua Bloch's typesafe enum idiom.

Converting from bare types to parameterised types was interesting - it forced me to determine the type of every collection, and it wasn't always obvious. By putting the type of the contained element with the collection declaration, it is easier for somebody casually browsing the source code base to understand it.

One very cute method buried in the JDK1.5 library is Arrays.asList(), which converts an arbitary bunch of parameters into a list. For example, we have this ugly code to build a list of three Strings and pass them to a constructor:


DispatchSourceTextGroup dstg =

    new DispatchSourceTextGroup(new ArrayList() {

    {

        add("FIRE INDICATOR PANEL");

        add("CFA-T3106130011-1");

        add("FULL CALL");

    }

});

Naively converting to generic types yields this typesafe, but even uglier code:


DispatchSourceTextGroup dstg =

    new DispatchSourceTextGroup(new ArrayList<String>() {

    {

        add("FIRE INDICATOR PANEL");

        add("CFA-T3106130011-1");

        add("FULL CALL");

    }

});

Arrays.asList() lets us write this comparatively nice code instead:


DispatchSourceTextGroup dstg = new DispatchSourceTextGroup(

    Arrays.asList(

            "FIRE INDICATOR PANEL", 

            "CFA-T3106130011-1",

            "FULL CALL"));

My only gripe is that it is not obvious (from this usage) why the method is on the Arrays utility class. Perhaps it could be aliased to Collections.asList() in a future release?

The new for loop syntax gave us some good wins too. For example this nested loop:


public void checkExtrasGuids() {

    for (Iterator i1 = extrasMap.keySet().iterator(); i1.hasNext();) {

        String kioskName = (String) i1.next();

        for (Iterator i2 = ((List) extrasMap.get(kioskName)).iterator(); i2

                .hasNext();) {

            DispatchExtras extras = (DispatchExtras) i2.next();

            checkKioskHasGuid(kioskName, extras.getDispatchGuid());

        }

    }

}

becomes more understandable:


public void checkExtrasGuids() {

    for (String kioskName : extrasMap.keySet()) {

        for (DispatchExtras extras : extrasMap.get(kioskName)) {

            checkKioskHasGuid(kioskName, extras.getDispatchGuid());

        }

    }

}                    

I didn't finish the port of this part of our application, but based on my progress over three hours, it would take two days to complete. My main area of concern is that we may need to move from Hibernate 2.1 to 3.0, which is being developed with JDK1.5 in mind.

Conclusion

JDK 1.5 gives our project some small but definite wins. They would be big enough to justify a switch from JDK 1.4, except for one thing: IBM has released Eclipse 3.0-based Rational tools which have some really neat features for visualising the structure of your application. Based on the trial version that I (finally, with much effort) downloaded, modelling tools will be more useful than language features, so JDK 1.5 can wait until IBM's tools catch up.

By alang | # | Comments (6)
(Posted to javablogs and Java)
© 2003-2006 Alan Green