Arnold Kling, "Arguing in My Spare Time", No. 7

In the previous essay in this series, I suggested that Java (tm by Sun Microsystems) can only be used by about 100,000 hard-core programmers. This would appear to constrain its importance. Another factor that will limit its impact is the applications for which it is used.

First, we should try to grasp the vision of the Java evangelists. In their scenario, a large application such as a feature-overloaded word processor would be replaced by a core word processor with additional features available on the Internet on an as-needed basis. Ultimately, according to this vision, programs become smaller. The integrated software bundle, which Microsoft lives by, will give way to lean, single-purpose programs.

The vision, as I understand it, is one in which software development is decentralized, distributed, and non-hierarchical. Java-based software development would be to contemporary software development what decentralized markets are to central planning.

For example, consider a tax preparation program (the word processor example has been used too much already). The pre-Java way to write such a program is to formulate a central vision for the program and then farm out the pieces to developers, each of whom will receive clear directions as to what to produce.

The decentralized approach would allow anyone to develop a re-usable component. One company might focus on depreciation schedules. Another company might focus on modeling the W2 form. And so on. None of these companies would have to communicate with one another. They would simply build the best components they could for their particular specialties, and users would call on whatever components they needed in order to prepare their taxes.

The way softare is developed today, integration is built in by the software developer. If any function is left out, there is little or nothing that the user can do. Hence, the natural tendency is for programs to become larger and more feature-laden. In the Java vision, integration somehow occurs in the background, and the user can request components on the fly.

I am not aware of any work in Java that has moved in the direction of achieving the vision of lean software applications to supplant integrated software bundles. (Corel briefly attempted to write an all-Java version of an integrated bundle, but this would not seem to qualify as an attempt to execute the evangelists' vision.) True, this means that we have no proof that this vision cannot be realized. After all, we have not seen any clear, convincing failures. However, the absence of activity that is headed in the revolutionary direction suggests that radical change is hardly imminent.

What is Java being used for? I see three broad classes of applications: "stupid Web tricks" on the client side; porting Dilbert-sector software to Web clients; and helping produce dynamic Web applications on the server side.

(Just to clarify, the "client side" of the World Wide Web is the software on the user's computer. Mostly, it is your browser, such as Netscape Navigator or Internet Explorer, but it may include add-ons, such as the Adobe Acrobat reader. If the Web were a 3D movie, the client software would be the glasses that you use to view the movie.

The "server" side is the software that runs at the other end when you visit a Web site. When my client--the browser running on my PC--sends a request to the Sonic Recollections record store Web site, a server in Portland, Oregon sends me a page of information.)

STUPID WEB TRICKS

By "stupid Web tricks," I mean some of the scrolling text, moving images, and other random decorations one finds on the Web. The first uses of Java were to create the programs to do these things. If that were all that one could do with Java, the language would die very soon, because (a) most users find these applets more annoying than helpful and (b) those same effects can be created more reliably and quickly by using new protocols for animated graphics and dynamic HTML. These newer techniques also require less programming skill.

DILBERT INTERFACES

Another use that has been found for Java, primarily in the Dilbert sector, is to create custom user interfaces. The standard Web interface is missing some capabilities that people find in very advanced programs. For example, if I am entering the name of a city, it would be nice if as soon as I type in "Balt" the program fills in "Baltimore" so that I do not have to finish typing. Some programs do that, but standard Web forms do not.

Another example is a sub-menu. In a proprietary application, if I choose "Virginia" from a list of states, I may see a new menu appear that lists cities in Virginia. The standard Web interface would require me to take two steps: choose a state, push a button, then wait for the server to send back a list of cities.

It should be pointed out that the standard Web interface has some important advantages: it is reliable; people are accustomed to it; and the functionality that it has is much more important to people than the functionality that is missing. In the vast majority of cases, the standard Web interface has sufficient functionality to make people happy.

Using Java to "enhance" the Web interface has costs and benefits. The benefit is that developer has more control over the functionality. The costs include:

--a less robust application. Java programs are more error-prone, and the slogan "write once, run everywhere" notwithstanding, a Java applet that works in one environment will not necessarily work in others. (An "environment" includes the user's hardware, operating system, browser brand and browser version number.);

--user confusion, because the custom interface is less familiar than the standard interface;

--issues with speed, because it can take a while for the Java code to transfer to the user's machine.

Another reason to avoid using Java to create a custom interface on the client side is the fact that other tools do this more easily. In fact, Java's tools for building dynamic forms (which would fill in most of the gaps in the standard Web interface) are less powerful and easy-to-use than those found in standard Web scripting languages (one of which is called JavaScript, although it is not truly a relative of Java).

My impression is that when a Dilbert-sector MIS department is asked to put a legacy application on the Web, the chances are very high that they will recommend using Java to customize the interface. However, the chances are very low that this a correct choice for the business. I suspect that the real problem that MIS shops have with standard Web interfaces is that civilians can write them, and this is very threatening from an ego and turf perspective. If the requirements of the application were assessed objectively and cost-benefit analysis applied, I doubt that Java would be used very often.

Based on the foregoing, it may turn out that in the long run Java will fail to hold on to any significant inroads on the client side. On the client side, the developer cares about things like string parsing and print formatting, capabilities which are very weak in Java. Creating a report-writing program in Java, for example, might require pages of code to achieve the same results as a few lines of a more appropriate language.

SERVER-SIDE JAVA

Java's strengths may be more suited to the server side than the client side. It takes relatively few lines to set up a Java program to process interactions between a client and a server. This makes it a useful language for performing the intermediate functions of processing a dynamic Web server application.

A dynamic Web server application is one in which the contents of the page sent to the user can vary according to what the user requested. The simplest example would be an interactive calculator, where the output will depend on the inputs. Another important example would be output that comes from a database query.

Many programmers are turning to Java to provide the background processing, including connections to databases, needed for dynamic Web pages. Just as with the client side, there are easier-to-use alternatives, such as Microsoft's Active Server Pages. But Java has a combination of flexibility and power that makes it very attractive for developing Web server applications.

Because serving dynamic pages is such a demanding task, it may turn out that "write once, run everywhere" is a dubious objective. Programs need to be moved into native code for performance reasons. We have found, for example, that a Java database query application on our site takes 2 minutes to return an answer, but it takes only a few seconds when we use a "just-in-time" compiler that translates the Java into native code.

If Java gains support as a development tool for the Web on the server side, that will be a significant achievement. Providing the engine for dynamic Web functions is a major market niche. If Java takes over this niche, then it will have found an important and enduring place in the computing landscape.

However, a tool for helping to build dynamic Web servers would fall short of the goal of changing application development from a centralized to a distributed process. A tax-preparation or word-processing application still would require top-down design. It could not be pieced together from disparate components.

One hypothesis is that Java is being hampered temporarily by a lack of development tools. It is conceivable that some company will come up with a high-level development environment that enables civilians to produce commercial-grade re-usable components in Java. The current development tools fail to achieve this, or even to suggest that this capability is within reach. If a company does come along that can design an environment in which non-programmers can write Java applications that can be used and enhanced by others, then such a development environment would indeed have the potential to launch a revolution.

The day of decentralized, component-based application development is not at hand. With all of the buzzwords that Java boasts (portability, object orientation, multithreaded, etc.), the phrase "suitability to task" does not jump out in any context. Even the dynamic Web server niche is highly fluid, with Java having drawbacks as well as advantages. One plausible scenario is that 1998 or 1999 will be the peak year for Java, and in two years the more ambitious visions will have receded.