email article printer friendly get the code

When Old Code Stops Working
Don't force upgrades with the latest and greatest development software. Give customers an upgrade road map instead
by Daniel F. Savarese

November 22, 2005

There is a camp of developers that has felt for a long time that Sun has been Java's worst enemy. From the tight grip Sun held over the platform and the resulting closed development model to numerous API shortcomings and even branding boondoggles, they had much to complain about. In the past two years, Sun has set almost everything right that many have felt it had done wrong.

Sun makes available weekly snapshots of the latest Java Development Kit (JDK) at its java.net portal. Licensing terms are more open than they have ever been. The Java Community Process (JCP) is more transparent and easier to participate in. Even the Java 2 branding has been replaced with something more sensible. If there ever was a real danger of Java developers jumping ship en masse, Sun has taken many positive steps to forestall that event. It may be too late to revive Solaris development, but Java development is only getting stronger.

Thinking about the way Java used to be managed has gotten me to thinking about old code. Recently, a programmer tried to convince me that I was doing the wrong thing by writing a class library that didn't depend on Java 5. I had chosen to remain compatible with JDK 1.2, but he was doing all of his development with the snapshot releases of JDK 6. The root of the disagreement was a difference in focus. If I were focused purely on my personal preferences as a developer, I would surely tie my code to the latest and greatest Java release. But I was focused on my customers' needs, which demanded that I provide compatibility with legacy software.

Reasons Galore
Customers often have good reasons to delay upgrading to newer versions of Java. Perhaps the most common reason is that old code may stop working. Bugs in a new Java Virtual Machine (JVM) may cause old code to stop working. This phenomenon was common during the first couple of years when just-in-time compilers (JITs) started to appear.

Changes in the Java language can befuddle old code. For example, the addition of new assert and enum keywords in the past two major Java releases have caused many programs to fail to compile. Changes in the implementation of JVMs can crash class files. For example, the JDK 1.0.2 compiler would inline final methods, sometimes generating bytecode where a private class member was accessed illegally. The JDK 1.0.2 JVM didn't generate any errors when executing such bytecode. The JDK 1.1 JVM implemented the Java specification more correctly and rejected such code.

The use of class file obfuscators also generated upgrade problems. Early JVMs were quite permissive about the symbols they would accept in bytecode. Later JVMs were more strict and would reject bytecode generated by obfuscators that relied on the use of invalid symbols. Early implementations of inner class compilation caused problems similar to those of the JDK 1.0.2 inline function access violations.

The addition of new classes, such as the MatchResult interface in Java 5 (which clashes with Jakarta ORO's MatchResult), can cause naming clashes that require you to change import statements or fully qualify class names. Adoption of new features before they've been fully debugged, such as the new I/O API in JDK 1.4, can cause you to wait for several maintenance releases before your code will work as expected.

I've covered only a handful of the situations where Java upgrades have caused problems in the past. There are any number of reasons why a customer must rely on an older Java environment. Only if you have both the source code to a program or library and the time to update them, can you circumvent legacy code problems. I'd like to take the opportunity to do a couple of updates of my own. Over the years, it has been brought to my attention that some of the code examples in my old Java Pro columns don't work. It's not that the examples didn't work when I wrote them. They just stopped working as newer Java releases passed them by.

The question I get asked about most often pertains to an old question-and-answer item I responded to in my column, "Step through AWT before You Swing," in the January 1999 issue (see Resources). At the time, the Swing API was still contained in com.sun.java.swing instead of javax.swing. A reader wanted to know how to place a JButton in a JTable cell and have the button respond properly when pressed. Apparently, the Q&A item is still published online independent of the column and pops up in Web searches from programmers who still have the same question.

Needless to say, the code no longer compiles because of the package name, but that's easy to fix. The problem people have with the code example is that it no longer works as advertised. At some point between JDK 1.1 and one of the J2SE releases, the implementation of JTable changed, and the technique I presented for using a button in a table cell stopped working.