Java's first decade has proven it to be remarkably adaptable. Originally conceived as an embedded language for consumer devices, Java emerged from Sun Microsystems in 1995 as the programming language for Web browsers. It then morphed into the leading tool for business computing and serious application development – in many ways the successor to both Cobol and C++.

Today, Java is the de facto platform for enterprise-scale applications, owing to its proven scalability and the extraordinary range of services it provides. In addition, the Java language has numerous properties that appeal to developers, such as object orientation, an expressive syntax similar to C and C++, few unsafe constructs, and built-in garbage collection. As a result, Java – as both a language and an execution environment – is likely to remain the platform of choice for enterprise business applications for many years.

To attain this central position in the enterprise, Java underwent extensive transformation. To remain at the centre, it will need to continue adapting to new technologies and responding to serious challenges, both from within and without the Java community.

Fast enough?

One key advantage Java offers developers is that it eliminates many practices common to C and C++ that can lead to inadvertent errors. The Java run time takes care of memory management and reduces the need to manipulate data items at low levels, but it does so at the cost of some performance.

Programs written with early releases of Java were significantly slower than their C and C++ counterparts. Because many Java programs of that period were applets designed to run in browsers, however, this limitation was more annoying than critical. Still, as Java moved into enterprise environments, the performance question became more serious.

This issue has been addressed in two ways. Moore's Law is one; with processor performance doubling roughly every 18 to 24 months, the delay caused by Java's semi-interpreted code has quickly become much less visible. The other speed boost came from improvements in just-in-time compiler technology. Early JITs generated code of middling performance quality, but JIT enhancements driven by academic research, investments from IBM and Sun, and the work of Swedish wunderkinder at Appeal Virtual Machines (acquired by BEA in 2002) resulted in better optimization and zippy execution environments.

Today, benchmarks show that Java has closed most of the gap between itself and its C and C++ forebears. Garbage collection – the process of reclaiming unused memory – remains one of the key factors working against parity in performance. The benefits of this feature, however – notably, more reliable code – are great enough that most shops are willing to accept this small penalty.

Write once, then what?

When it was first released, Java's mantra of portability was, "Write once, run everywhere." The more common experience that developers encountered, though, led to an alternative version: "Write once, debug everywhere."

In truth, Java's reputation for portability problems was merited only in the area of client-facing software, which indeed left much to be desired.

Today, even these problems have been largely addressed, owing to a succession of GUI frameworks that have done much to put client-side Java applications on a par with native implementations (see Client-Facing Java Perks Up).

When developers put aside their prejudices, they recognize that, although imperfect, Java does a better job of platform independence than any other alternative.

Today, Java and portability are frequently equated with little objection. This parity is especially true of server-side software that runs on the J2EE platform, consisting of database interaction, business logic, and generation of Web interfaces for data presentation.

Open source and community

As Java's popularity has grown, outside contributions to it have come from far and wide. Today, the Apache Software Foundation's Jakarta projects, JBoss, and the Eclipse and NetBeans IDEs, are just a few of the hundreds of thriving open source Java projects. Several large companies have made substantial gifts of Java code to the open source community, as well; none more so than IBM.

The popular Eclipse IDE from the Eclipse Foundation was seeded with open source Java code from Big Blue. In addition, IBM has open-sourced a significant amount of code from other projects, including the Cloudscape embedded database.

Many useful technologies – such as Struts, a Web interface framework – have become regular parts of enterprise Java development without ever obtaining Sun's official sanction. Occasionally, however, new technologies are offered up for absorption into the core Java libraries. The various contributors often have differing visions of how Java should evolve and how new technologies should be added to the platform.

Because of this, Sun is often pressured to relinquish control of the language and run time, and turn over custodianship to an independent body. Some users even propose a completely open source version of Java steered by the community. This idea has never gained wide acceptance (although it continues to make headway), because of fears that the platform would become fragmented.

Instead, Sun initiated the JCP (Java Community Process), which created committees to evaluate and develop technologies for the Java platform ( Perceptions of the JCP's success depend on whom you ask. Some observers deride it as slow and unresponsive; others say it's an excellent way of promoting new technologies and quietly killing off bad ones. All users agree, however, that it works better than having a single vendor make all the decisions.

The .Net threat

In 2001, Microsoft unveiled its purported "Java killer" in the form of the .Net development framework. Although the .Net run time supports several languages – including C++ and Visual Basic, both of which have large followings – Microsoft gave its new flagship language, called C# (pronounced "C-sharp"), a syntax remarkably similar to that of Java. It also borrowed Java's concept of semicompiled code, managed memory, and a hosted execution environment that could enforce certain security constraints.

In addition, it added competitive features such as the ASP.Net language, which makes constructing Web interfaces straightforward (a task with which Java has long wrestled).

Yet within a year of .Net's release, it was clear .Net was not drawing a significant number of developers away from Java. On the other hand, the difficulty of transitioning the existing Windows code to the new frameworks presented Java an opportunity to lure dissatisfied Microsoft customers. Today, a mix of both technologies is commonly found at customer sites.

Java frequently has the enterprise-computing role, whereas .Net is used for smaller projects. Moreover, signs point to a closer relationship between the two technologies in future.

In 2004, Sun and Microsoft finally settled their bitter court fight over Microsoft's customized version of the Java execution environment, and now these old adversaries claim to be partners.

Recently, Sun CEO Scott McNealy intimated that his company will work toward greater integration of the Java and .Net run times. It's hard to assess what this means, but certainly one can hope that eventually objects written for one platform can be made easily accessible to the other. Today this can be done only through WS or cumbersome proprietary technologies.

Complexity crisis

Many of Java's enterprise technologies are under revision, owing to a problem that has pushed its way to the forefront: the complexity of enterprise development. With all the various additions that have made their way into the core specification, J2EE has become a grand but Byzantine collection of technologies that includes enterprise messaging, e-mail services, database connectivity, a naming and directory interface, a transaction apparatus, and so on. The attractiveness of such a comprehensive offering is that it enables you to handle any enterprise task -- except, of course, writing simple programs.

Becoming expert in all the necessary technologies is a near-impossible requirement for J2EE developers. There are simply too many technologies, and each one could be a specialty unto itself. Consequently, architecting, writing, and debugging J2EE applications are daunting tasks.

Many sites, therefore, have opted to use a subset of the full J2EE specification. For example, they will rely on a single container such as Apache Tomcat, access the database using JDBC, and handle the client-facing interface with Struts. These technologies enable them to do much of the bread-and-butter enterprise development without having to embrace the entire J2EE sprawl. For large, complex applications, however, J2EE remains the only workable solution.

Canned beans?

A second problem with J2EE lies in one of its most prominent features, EJBs. EJBs are hard to write, implement, and unit test. They constrain the use of inheritance and rely on complex models for persistence of data – that is, for saving data to disk.

Despite important revisions coming to the EJB standard, many developers have looked to other options. Fortunately, the open source community has provided these in the form of frameworks that handle much of J2EE's complexity transparently. Hibernate and Spring are two of the most popular.

Hibernate is a framework for persisting objects in a relational database. Although not as comprehensive as other, similar frameworks, its elegance and its support for the majority of needed functions without being overly complex have made it widely popular.

Spring, on the other hand, is a lightweight framework that uses POJOs (plain old Java objects) rather than EJBs. This design makes it easier for developers to write and test components and applications. Spring plays nicely with Hibernate and other emerging persistence frameworks.

Sun, meanwhile, has been working on a new version of the EJB specification, part of an overhaul of J2EE called J2EE 5.0 aimed at making it simpler for programmers to access and use services. J2EE 5.0 brings annotations and metadata to Java code, allowing developers to specify object attributes in shorthand. Sun also will make greater use of POJOs, which are inherently easier to develop, use, and especially test. Sites considering new J2EE projects should give serious thought to this transition.

10 more years

Historically, programming languages begin their decline as they become bloated. C++ is the definitive example of this phenomenon, but other languages, such as APL and Cobol, certainly demonstrate the same dynamic. Unlike these precursors, Java is undergoing a process of renewal and simplification, which portends well for its long-term viability.

What does the future hold for Java? Java developers are already abundant and busy. The Java community is dynamic and innovative and the language is thriving. I'll bet that in a decade we'll be celebrating the 20th anniversary of the language. Until then, happy birthday, Java!