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.
View a complete list of OSCON contacts