By most people's estimate, it's the fifth anniversary of Java. Five years ago, with Netscape in tow, Sun unveiled Java, declaring that the Java programming language would be the next Web revolution. At the time HotJava was the "killer app" for Java; more a proof of concept than a competitive browser platform, it demonstrated that there could be more to the Web than plain old HTML.

Within a year all the major browser platforms included a 1.0 version of the Java Runtime and applets were considered the next big thing after plug-ins. Both, it turned out, were pretty much useless for e-commerce and interactive Web sites: all the action was on the server. Java was declared dead by many industry pundits and its role on the client side of the Internet equation diminished massively.

Sun and other vendors began accordingly to shift their attention server-side, since computing application servers were becoming the new operating platforms for the Internet. After three years this effort has emerged as J2EE, arguably one of the fastest-growing enterprise computing architectures in history.

Why is all of this so important? It matters because today, while Java is on the threshold of being established as a new-breed operating platform for the Internet, many customers and developers still understand it, narrowly, as an Internet programming language.

With the metamorphosis of Java from cool Internet programming environment to foundation platform for Internet applications comes a need to rearticulate the role of Java the platform versus Java the language. As Java becomes more strategic to the industry overall, the transformation also raises fundamental questions for customers and vendors about the openness of the platform.

If Java is to the Internet environment what Windows was to the PC environment, and if by definition foundation Internet technologies require open architectures, then we're faced with a long-term question about the overall openness of Java. In the Internet environment, there are really four major categories of technology, each with their own degree of openness:

1. Open standards-based technologies: The vast majority of technologies running the Internet are based on open standards created by vendor-driven standards bodies such as the IETF, W3C, ISO and ECMA. These include TCP/IP, HTTP, HTML, XML, RARP, X.509 and hundreds of other core technologies. These standards still rely on vendor or community implementations.
2. Open technologies defined by process and license: A vast amount of Internet technology in place today is literally and truly open in legal terms, typically as defined by the General Public License (GPL) or a BSD-style license. These technologies include operating systems (Linux), Web servers (Apache) and application development and runtime technologies (Perl, PHP, Python, C/C++, and so on).
3. Open technologies defined by process, but not license: This includes vendor-controlled technologies but with an open community process in the evolution of those technologies. Great examples of this include Java or an older example such as ODBC, driven by Microsoft. Nonetheless, in both cases a single vendor ultimately owns and controls the technology.
4. De facto standards with broad distribution: In many cases, commercial success with a proprietary technology establishes a de facto standard position for a vendor technology. Examples of this include Microsoft ASP, Allaire ColdFusion, RealNetworks RealMedia and Macromedia Flash.

The Diminishing Role of Java
Ironically, as Java becomes an operating platform, more and more uses of the technology will diminish Java's visible role to the ultimate user. It's critical that developers and IT managers understand this shift and take off the Java blinders, as it were, to help them understand how to apply the platform overall.

Two key examples come to mind in which Java is the runtime platform but not the end-user technology: dynamic page engines and scripting environments, and XML protocols and Internet middleware.

Dynamic page engines and scripting environments
Over the past several years a dominant model has emerged for delivering page-based Web applications. This page-based scripting model typically separates the task of dynamic content generation, basic user interactivity and simple application logic into a template- and script-based environment. Often this tier is combined with a business logic tier implemented using a component object model such as COM, CORBA or EJB, with the implementation environment typically C++ or Java.

Interestingly, the popular page-based scripting models (ColdFusion, ASP, JSP) are increasingly trying to abstract away the lower levels of complexity required by traditional system programming. In ColdFusion and JSP, for example, the ideal programming model becomes tags and tag libraries used by designers and interactive developers to put together a user experience. In this model, while Java may be the runtime platform (it is, in fact, the ideal runtime platform for this dynamic page tier), it's essentially invisible to the developer. And this is a very good thing. Java programmers should be happy to know that their platform is the foundation but that others are using it without the complexity of the full language.

XML protocols and Internet middleware
Another great example is emerging XML protocols for distributed application integration, including protocols for distributed objects, messaging, transactions and security. While J2EE provides an outstanding runtime environment for such protocols and interfaces, the use of these XML protocols will increasingly be divorced from developers knowing anything about the actual Java runtime. In most cases XML middleware will connect applications written in scripting environments such as JSP, ColdFusion, Perl and ASP rather than full-blown EJBs.

Both of these examples illustrate an ultimate paradox ­ which is that as Java becomes more and more successful as a platform, it will grow less and less visible as a language. It's critical that developers embrace this idea and open up to the fact that while not every application or system may be implemented in the Java language, ultimately it will still be running on Java bytecode.

The fact that these kinds of observations and discussions are happening symbolizes the incredible power and success of Java. With this power comes a degree of responsibility to vendors and customers with regard to redefining Java's role in computing. Whatever the case, happy fifth birthday!