A programming API represents a documented contract between a function that provides some kind of computing service and those who wish to use it. In Java, once an API is used there is a physical contract between the two that the compiler and JVM enforce. If at some point in the future the author of the API wishes to make changes, they are limited in scope; if the author renames methods or removes arguments, programs that are bound to the previous signature will no longer run. The change can be published with the new version of the class library or framework so that users can upgrade their code; however, in many cases this isn't a viable option. It may be that the system that used the old API is no longer being worked on by a development team and is considered stable, or that the release cycle of the now broken system is dependent on other circumstances that prevent it from being upgraded.

No API can be got right the first time, irrespective of how many specifications, architecture meetings, and examples take place prior to its release. The whole idea of launching a set of class libraries and Javadocs onto the world as being the eternal way of doing something goes against the whole philosophy of agile programming. One of the principles of extreme programming is that a good program is built flexibly and in a fluid state; at each stage the feedback loop of usage and reconstruction means that the right solution is arrived at by accident rather than by design. This is akin to evolution, whereby variations in a species arise by random mutation and are mixed in offspring to create new individuals. The fittest varieties survive whatever the environment provides and the cycle continues, allowing the species to adapt and evolve.

The Java language has maintained its API over many releases so a program that is compiled on 1.2 will run unchanged on a Java 5 runtime environment The benefit of this is that older Java programs remain functional on modern JREs; however, it comes at a price. The language now contains a plethora of deprecated classes and methods, new features are sometimes sacrificed to ensure backward compatibility, and the evolution of Java is hindered and held back. The class java.util.Date, for example, has more public deprecated methods than non-deprecated ones. Not a lot has changed in the domain model of Dates since the Gregorian calendar was introduced in 1582, and this ratio of legacy to current API is a sign that code change is a natural flux that occurs during its usage.

In nature the extinction of a species is not a gradual thing but comes in waves. Punctuated Equilibrium describes an effect whereby the environment remains fairly static for a while and then a huge amount of change occurs in a small amount of time. These boundaries are mass extinctions that not only cause many species to die out, but are also the event that allows others to flourish and fill the void left by the departing ones. To a certain extent Java benefited from this back in 1995, when it was born out of a combination of the best ideas of C++ and Smalltalk; the catastrophic meteorite striking at the time being the Internet and demand for heterogeneous networked computing.

What worries me 10 years later is that I don't believe Java is evolving fast enough, and that strong typing to antiquated APIs are holding it back. XML won over a slew of competing technologies for program-to-program communication transport because it is text based, allowing it to be read by heterogeneous end points (as opposed to alternatives like CORBA IDL or other binary RPCs). XML is also flexible in its typing, because tags can be declared as optional and new tags can be introduced in a message without breaking callers using the older format. While Java has done well as an enterprise language in the application server space, this is largely due to the fact that the big names of IT backed it rather than any inherent feature of the language. Languages such as Ruby and Perl have grown tremendously in the past few years and now command a sizeable portion of application development.

If Java is to remain at the forefront of technology for the next 10 years, it must find a better way to evolve. It needs to find a way of decoupling API calls between internal code and external blocks, perhaps even introducing soft typing calls across program boundaries or having flexible message transport across modules. While XML parsing functionality is now included in a Java runtime by default, it feels very shoehorned into place when compared with how .NET has done the same integration. Older languages like COBOL or RPG, as well as Visual Basic, include the concept of structures into a program definition that can be externalized, and having Java include a slew of JARs and runtime bolt ons to do simple XML parsing seems a missed opportunity to embrace the technology.

Becoming strong enough to do battle with Microsoft, the T-Rex of computing, may have fared well for Java in the past, but at the expense of what it has now become and how quickly it can keep up with change and the legacy it has created. I fear that unless a fundamental change to the language is made that allows more flexibility in binding between functional units, between and across JVM boundaries, Java will be a victim of the same fate as the behemoths it fights in the IT tar pit. Survival against change - whether in nature, technology, or business - is determined by ones ability to adapt. Java needs to move forward by being more agile. As the language grows with more and more APIs and divisions, it runs the risk of losing sight of the finish line, while smaller and nimbler technologies become more ubiquitous. When the next IT meteor strikes, Java must be the fastest to adapt if it is to survive and grow over the next 10 years.