Columns

Java Observer

• By Peter Fischer, Max Dolgicer
• July 24, 2001

No one can deny the unprecedented fervor that surrounds Java as the ultimate programming language. It has been highly touted as the language to be using to program all your Internet/Intranet applications today.

The biggest manifestation of this is the tremendous number of Web pages -- characterized by dazzling, scrolling graphics -- activated by Java applets.

Is this the only way in which to leverage Java as a programming language? The answer is no. There are two different ways to run a Java executable: either as a standalone application or as an applet that is embedded in a Web page. Significant differences between the two executable models exist and will factor in how Java is used to build systems, now and in the future.

What is an applet?

Let's start the discussion with by far the biggest use of Java to-date -- the applet. Applets were originally intended to supply small, finite units of functionality for activating Web pages and have held true to that promise to this day. However, as Java has matured, applets are now seen as one way of delivering component-based functionality to Web pages. The original intent is that applets would be small applications -- hence the name. As Java matures and its use for creating active Internet and Intranet applications increases, this distinction will become irrelevant. Instead the distinction will be based solely on technical characteristics.

Java applets leverage and take advantage of features that are built into Web browsers. This enables developers to write applets that can contain a rich amount of functionality with a minimal amount of code. One of the major uses of applets is to display graphics and images. To incorporate GIF or JPEG files into a Java applet, it is not necessary to write any special decoding methods to interpret the image files. Instead applets can use the browser's built-in decoder to display the images.

Using the functionality built into the browser offers an applet a good degree of extensibility. If a new image file format becomes the hot format and is incorporated into the browser, the Java applet will automatically be able to handle the new format without any custom code having to be written.

An applet has no life outside an HTML page that is being processed by a browser. Thus the browser is the "container" of the applet and depends on the browser to call its methods. There are a lot of restrictions on the functionality of an applet. If you think about this, it is not unreasonable when you consider that an applet is an invited or uninvited guest that borrows your machine to execute and display.

Because applets run inside the browser container, the distinction about whether such restrictions derive from the browser or are inherent in the language often get blurred. This has a significant impact on the functionality that an applet can have. In a sense, a specification between the browser and the applet exists, which is driven by both the browser and the Java language. This is dictated by the Java Security Manager component that is part of the browser. When you select the Options Security menu item in Navigator, the Java selections in the dialog are controlling the level of security enforced by the browser. By the way, no real security specification for browsers exist, just a de facto acceptance of what security really means in the context of a browser running foreign code.

Four major types of restrictions are imposed on applets. First, an applet has limited access to the local and remote file systems. This is due in part to both the security features of Java as well as the browser. Both Netscape and Internet Explorer simply forbid all access.

Second, an applet class that was loaded from the Internet is not allowed to make any native calls. These remote classes cannot execute any local commands. This restriction is lifted for classes that are used by the applet but are loaded from the local machine. Some examples of such local classes are base classes such as Object and Component. Third, an applet cannot be a network socket server and may only open a socket connection to the server machine that served the applet's HTML page.

Lastly, there are restrictions imposed on inter-applet communication that are also driven by the browser. Netscape Navigator, versions 2.x, limits all inter-applet communications to applets on the same HTML page. Navigator 3.0 further restricts these applets to come from the same directory on the Web server and to have the same level of support for JavaScript.

An applet's life cycle begins when the user visits the Web page that contains the applet. After constructing the applet, the browser allocates a place for it within its viewing area on the screen.

At this juncture an important event occurs -- the applet is assigned a peer. What is this thing called a peer? It is the essence of the platform independence that makes Java such a powerful programming language. In the nutshell, a peer is an applet's connection to the local, platform-specific underlying Windows system. This peer is an inherent part of the Java virtual machine for that platform. Java components, which include applets as well as applications, receive much of their functionality by using the facilities of the local Windows system.

Next the browser sends several startup method calls to the applet. The first applet method that is called is init. This method is only called once and all one-time initialization for the applet is done here. Such functionality includes creating the applet's GUI and reading in the parameters. The browser then follows this with a call to the start method which basically puts the applet into the "active" state. This means that the page that houses this applet is now the active page in the browser.

When the user navigates away from this page, the browser calls the stop method, putting the applet into the "inactive" state. The applet is running and is not destroyed because many browsers cache Web pages.

When the applet needs to render its representation in the page, the paint method is called. As applets tend to be graphical in nature, this is where most of the processing action occurs. This method is called the first time the applet is displayed and any time that its needs to be repainted.

The destroy method is called when the browser no longer needs the applet. In reality, because most browsers cache the applet when the Web pages gets cached, this method is rarely called.

Whew, there is a lot of stuff going on here! In reality, an applet is simply a finite state machine that provides methods that are called on demand by the browser. It is a reactive component completely controlled by the browser and whose main responsibility is to implement the correct methods for it to function correctly.

What is an application?

An application is basically a program that just happens to be written in the Java language. At a high level, it is just like any application that is written in another programming language. From the Java perspective, an application runs without a browser, a security manager and without applet context.

An application is invoked from the command line by passing the class name of the Java application to the Java runtime and when execution starts and stops. It is the proactive voice in the execution context.

In general, applications have an easier lifestyle compared to applets. They have complete access to the file system and network, as you would expect from any typical application. They can also invoke native methods. Native methods are basically code that is written in another language such as C that is called from Java. In a way, it permits access to "legacy code" (from the Java perspective, of course) from Java. This gives them the ability to be very functional as compared to applets.

If the picture seems rosy for an application, it is for the most part. The one drawback to being an application is that the peer is not created automatically. Fortunately, most initialization activities do not require the presence of a peer. Usually this is not a big issue except in one instance, which is when dealing with images. In this case the peer must be created by the Java application programmer and assigned to the application before any image creation routines can be called. This is just one of the basic rules of Java programming. All languages have them.

As applets are called upon to perform more functionality, the support for interactions between applets, browsers and network resources can be expected to mature and become more refined. Some of the more recent advances have been signed applets, which provide the basis for secure electronic commerce as the Java Wallet technology. As new uses for the Internet and Intranet emerge, Java and applets will be sure to evolve with them.

Most of the use of Java is directed towards building applets, which enhance and activate Web pages. As more and more businesses and corporations adopt Java as an enterprise language, the use of Java applications will become more prevalent. Certainly, the recent release of the Java Enterprise technologies (Java RMI, JDBC) positions Java applications as distributed-object applications for the enterprise. Applets are the shining star of Java currently, but Java applications are just starting to glow.