Learning Java, 4th Edition

The Politics of Browser-Based Applications

First, a bit of history. The potential for applets to add dynamic content to web pages was one of the driving forces behind the spread of the Java programming language. Prior to Java’s introduction in 1994, there was really no standard way to do this; even the now-ubiquitous animated GIF images were not yet widely supported. Sun’s HotJava Java-based web browser was the first to support applets. It was Java’s original “killer application.” Later, in 1995, Netscape announced that it would support the Applet API in its browsers, and soon after that Microsoft jumped on the bandwagon. For a while, it seemed that Java would power the future of the Web, but there were many bumps in the road to come.

Many problems, both technical and political, plagued the early years of Java’s use in browsers and client-side applications. Performance issues were to be expected in such a young platform. But what really crippled Java early on was the nonportable and buggy AWT, Java’s original GUI toolkit. Many people overlook the fact that Java’s success as a portable language is in large part a result of just how much of the Java API is implemented in Java. You might be surprised to learn just how many Java internals involve no native code—everything from cryptography to DNS is done in Java—requiring no porting for new platforms. Similarly, the renaissance of Java GUI applications seen in later years was due almost entirely to the introduction of the pure Java Swing GUI toolkit. In contrast, the original AWT system was based on native code, which had to be ported to each new system, taking into account subtle and tricky platform dependencies. AWT was effectively a large, graphical C program that Java talked to through a set of interfaces and Java was, to some extent, unfairly painted as nonportable and buggy by association.

Java faced other, less technical obstacles as well. Netscape foisted the original AWT upon the world when it insisted that Java be released with “native look and feel” in lieu of a less capable, but truly portable, graphical toolkit. It later introduced a pure Java GUI toolkit called IFC (an ancestor of Swing), but it struggled to gain traction. Later, Microsoft effectively stuck us with AWT by freezing the level of the Applet API in its browsers at Java 1.1. Applets languished with poor GUIs while lawsuits between Sun and Microsoft dragged on in the 1990s. The result was that support for applets in web browsers remained a mess.

Sun made an attempt to insulate Java from the browser battles with the introduction of the Java Plug-in. The Plug-in allowed applets to run in an up-to-date Java VM, but by this point lacked the critical mass and near-universal adoption necessary to make such a plug-in useful. The weaker but more prevalent Adobe Flash plug-in flourished, as developers desperately wanted a way to deploy richer applications to the browser. In the 2000s, JavaScript and HTML matured greatly and made the browser itself more of a viable platform for deploying software, leading to the great irony that JavaScript, the slower and less capable namesake of Java, became the de facto programming language of the Web.

Find it a bit depressing? Well, take heart; JavaScript has evolved into a worthy platform for the client side, Flash is fading, and Java has dominated server-side development and made possible portable libraries that have fueled much of the Internet revolution. We cannot say what the future holds, but Java in some form will likely be a player in it for many decades to come.