Java in a browser eliminates the need for CGI scripts and programs

Java applets will replace some uses of the Common Gateway Interface. Prior to Java, the only way to create a web page whose contents are not static was through CGI scripts or programs running on the web server. In some cases, this server-side code can be replaced conveniently by Java applets running in the browser. In many situations, however, browser-side Java can't be used in place of CGI. The reasons may involve security (do we want password validation code running in the interpretive Java environment, where a clever user could disassemble them?) or performance constraints that Java's interpretive environment can't satisfy.

In a lot of cases, Java will let us do things that CGI supported badly if at all. Client pull and server push are brute force, high overhead techniques for creating interactive pages. By eliminating the need to communicate with a server, we can create truly interactive pages. An example is this clock applet, which tells me that I have owned the disordered.org domain for an unknown number of days (an unknown number of weeks or an unknown number of years). These three instances of a particular applet class share a thread, which updates their display every eight seconds. A CGI-based equivalent would require communication with the server on every update.


In the short term, we may have to use CGI mechanisms simply because Java doesn't give us access to the resources we need. To write a web browser-based database query application, we would set up a form to capture the input and ship it off to a CGI script on the server. This server-side program would validate the data, run a query against the database and generate a new HTML page with the result. A Java applet could be used to replace server-side data validation, thereby improving user response in cases where the input is invalid. (No wait for the browser to communicate with the server and the server to send the error back.) If we have a Java class interface to the database (and our concerns about security don't keep us from using it), we could implement the query and display in Java as well and eliminate the server-side code.

This discussion ignores two other points: that JavaScript will sometimes be a preferable to Java for browser-side programming; and there are now opportunities to invoke server-side Java code in the form of servlets. Java on the server has many of the same advantages and disadvantages over other server-side languages that Java has as an application language. A large advantage of Java servlets is that it saves the process creation overhead inherent in CGI, particularly in situations where there will be multiple interactions between browser and server to satisfy a request; there are disadvantages as well in the increased complexity of the debugging environment for such code.