The concept of “technical debt,” originally developed by Ward Cunningham, typically occurs in systems while adding new features or during maintenance and bugfixing. The phrase “we’ll fix that later” is usually a good indicator of technical debt. The use of debt as a metaphor is quite apt, as there are many parallels with taking out a loan in order to buy something now, while paying for it later, along with the accrued interest. Many projects, including OpenJDK, suffer from a burden of technical debt, where the accumulation of delayed cleanup projects slows down feature work and makes maintenance more difficult.
OpenJDK is an open-source implementation of the Java platform. Much of OpenJDK is implemented in Java, and so when the Java platform evolves, it makes existing code go out of date even though it hasn’t changed. For example, prior to the addition of generics, all types were “raw types.” When generics were added in Java 5, many APIs were updated to use generics, but much of the internal JDK implementation was not. This implementation code still ran fine but was now essentially out of date. Worse, mixing generic and raw types results in compiler warnings. At one point there were over 10,000 warnings emitted during the JDK build, when all compiler “lint” warnings were enabled.
In any project, there are many impediments to reducing technical debt. The benefits of adding a new feature are clear; the benefits of cleaning up old code are diffuse. There is opportunity cost. “Code cleanup” is not a very glamorous job description with which to attract talented developers. OpenJDK has the additional constraints of compatibility. Public APIs cannot be changed without going through the Java Community Process (JCP). Some implementations cannot be changed without breaking application programs. Newer constructs sometimes have subtle semantic differences from the old ones that prevent simple drop-in replacement. In these cases a good deal of analysis might be necessary to prove that making an apparently innocuous change doesn’t introduce an erroneous change in behavior.
Despite these issues, we have managed to make some progress reducing technical debt in OpenJDK. We have targeted and slowly resolved the most serious issues found by FindBugs. There have been several activities aimed at reducing warnings in the JDK build. We have also made a “coinification” effort to introduce the Java 7 “Project Coin” constructs into the code base. However, there is much work left to do. The Oracle JDK team will continue these efforts during JDK 8 development, and we welcome involvement from the OpenJDK community.
Stuart Marks is a Principal Member of Technical Staff in the Java Platform Group at Oracle. He is currently working on enhancing the core libraries of the JDK. He has previously worked on JavaFX and Java ME at Sun Microsystems. He has over twenty years of software platform product development experience in the areas of window systems, interactive graphics, and mobile and embedded systems. Stuart holds a Master’s degree in Computer Science and a Bachelor’s degree in Electrical Engineering from Stanford University.
For information on exhibition and sponsorship opportunities at the conference, contact Sharon Cordesse at (707) 827-7065 or firstname.lastname@example.org.
Download the OSCON Sponsor/Exhibitor Prospectus.
View a complete list of OSCON contacts