Java —

The Internet

C evolved from a systems language built to create operating systems. It's a systems programming language. C, and the C++ follow-up language, didn't creep into the enterprise until later. Unlike C++, a very early target for Java was mobile computing, and it evolved very quickly to encompass Internet applications for the enterprise. You can easily see Sun's intentions in four primary places:

  • Java included convenience features to make applications programming easier. Java added garbage collection and memory management, so application developers wouldn't have to deal with these issues. Java included first-class strings, so the platform, rather than the programmer, could deal with moving the individual bytes around. A systems language might want more control.

  • Java's vision for enterprise computing was centered on the Internet. Java built in several libraries that greatly simplified enterprise computing and the growing language always kept the Internet as a central focus. Early APIs enabled everything from communications protocols like TCP/IP sockets to the applet framework that allowed embedded applications in a browser.

  • Java's fathers keenly moved to improve simplicity, at the price of low-level flexibility. For example, though C++ could touch any byte in the system, they knew that the C++ applications community struggled with pointer arithmetic.

  • Very early, Java was targeted at mobile applications , but Sun saw an opportunity to topple Microsoft. Sun took the opportunity, extending the primary focus of Java into the Internet.

Remember this: client/server computing made it very difficult to deploy applications. Thousands of Windows clients, and a distributed network of hundreds of servers to power them, were cheaper than mainframes to buy, but they were horrendously expensive to manage. In the late 1990s, corporate visions changed from client/server computing to networks of applications built with Internet standards, called intranets, existing entirely inside corporate boundaries. When Sun embedded Java into the first version of Netscape Navigator, this vision looked quite possible.

A Consistent Evolving Vision

The ultimate goal for the Internet is this: give all users a single application platform (we call it a browser), and give them the ability to run applications in it. Initially, those applications took the form of applets. It was a simple ideaembed the JVM into a browser, and let the user just download Java byte code that makes up an applet as one more message (MIME) type. The browser would just hand the applet to the JVM. Initially, many companies deployed their first few applets with great success. Later, applets fell out of favor. Over the course of my interviews, I found broadly different views of why they failed:

  • Deployment was hard. Applet developers discovered that they had traded one problem deploying operating system upgrades and client applications for another deploying the ever-changing browsers, and synchronizing virtual machines.

  • Programming was hard. Applet developers had a hard time understanding an alien programming model, and integrating the applets seamlessly with the web page. Applets done well were often magnificent, but not many applets were done well.

  • The Netscape JVM was buggy. Some said that the buggy Netscape JVM killed applets single-handedly. If Netscape had better supported the notion of a pluggable virtual machine, applets might have had a better chance at success.

For whatever reason, applets faded into the background. But Java is a surprisingly nimble beast, at times. In the halls of Netscape, server-side Java emerged. Servlets made server-driven Internet applications available to application developers. Sun capitalized on this movement quickly with a standard, and an open source implementation of a servlet engine called Tomcat . Servlets solved many of the problems of CGI-based applications, and enterprise developers had a new way to deliver applications to a desktop. The vision of an application in a browser remained, but the view logic had moved from client to server.

The server would build dynamic content and serve it to the client. Ironically, this "new" model was little more than a glorified green screen that you might find on a mainframe terminal or emulator. It did have some important subtle advantages:

  • While green screens were stodgy and old, the Internet was cool and new. Users knew how to use them because they had the Internet at home. They liked to use the new systems as much as developers liked to build them.

  • Browsers lacked the raw productivity of keyboard-driven interfaces, but it was much easier to train users on them. The user interfaces provided several subtle enhancements, like navigating through links instead of typing menu choices.

  • The server-side development environments were much more productive than their mainframe counterparts. Development environments, often Windows clients, were much cheaper.

Java's client-side development stagnated. Swing has long been criticized for providing a poor user experience, but the real limitations lie in the learning curves and ultimately the productivity of developers that must grab it by the throat and shake to merely coax a minimal application out of it.

But Java's emphasis quickly moved wholly to the server side, where it remains today. Java Server Pages (JSP) continued the evolution, making it easier for traditional designers to play a role in the development of web applications. More modular designs, with JSP tag libraries, portal components (called portlets), and MVC frameworks, continued the evolution. None of Java's user interface technologies has succeeded on the same scale of web-based applications, driven from servlets.

Moving Forward

The vision of Internet applications is not yet complete. Google is now experimenting with Ajax , which seeks to provide a better experience to users with generated JavaScript and XML that communicates with the server. Applications like Google Maps show that it's possible to create richer applications with JavaScript and active communication between the client and server, but we desperately need a new user interface technology providing the advantages of easily deployed servlets and the richness of applets. JavaScript is broadly available, but it's a haphazard, problem-prone scripting language that's different on each different browser.

My intuition tells me that the ultimate answer won't look much like a browser, but will have many of the same characteristics. You can well imagine that a better marriage between a browser and a dynamic language would make it much easier to give the user a richer experience. One thing to me is clear. The Java community has not had much success with richer clients. The mainstream rich client technologies of Swing and the Standard Widget Toolkit (SWT) keep the programmer at a very low level. Microsoft and Apple both have much better frameworks. While Java does do web-based development very well, increasingly users will demand a richer experience as they have access to more bandwidth and ultimately see the incredible power that a richer experience can unleash.