The Garbage Collected Heap

The garabage collected heap is the store of memory from which class instances are allocated. It is the job of the interpreter to provide handles for the memory needed by a class for execution. After this memory has been allocated to a specific class instance, it is the job of the interpreter to keep track of this memory usage, and, when the object is finished with it, return it to the heap.

The Java specification does not enable a programmer to control the memory allocation or deallocation of objects, except in the new statement. The reason the designers chose to implement Java in this manner is for portability and security reasons that were mentioned before. Because of this, the job of memory deallocation and garbage collection is the responsibility of the runtime environment. The implementor must decide how this garbage collection is carried out. In Sun’s Java and HotJava environments, the garbage collection is run as a background thread. This provides the best possible performance environment, while still freeing the programmer from the dangers of explicit memory usage.

The Memory Area

The JVM has two other important memory areas:

•  The method area. The region in memory where the bytecode for the Java methods is stored.

•  The constant pool area. A memory area where the class name, method and field names, and string constants are stored.

There are no limitations as to where any of these memory areas must actually exist for two main reasons. First, for a portable system, making demands on the memory layout creates difficulties on porting to systems that could not handle the specific layout chosen. Second, if there is a specific memory layout, it is easier for someone attempting to break a system to do so by knowing where their code might be in relation to the rest of memory. Thus, memory layout is not only left until runtime, but is specific to any implementation.

Setting Up Java Security Features

All of Java’s security features so far have focused on the inherent security and stability of the Java environments themselves. These are essentially passive techniques that Java manages for the user. Java also provides the means to set security levels such as firewalls and network access on the client side. These techniques can be seen in the Appletviewer that accompanies the Beta JDK. Netscape has decided to implement a much more rigorous security level with its Java implementation, and limits all access that an unsigned Java applet can have. In the end, the only choice is whether to run the applets at all. Although it is not the purpose of this chapter to show how to set up the entire JDK release, it is necessary to review the options with several of the tools such as Appletviewer and Netscape 3.0, which could expose your system to an attack.

Using the Appletviewer

The Appletviewer provides a Java runtime environment within which Java applets can be tested. The Appletviewer takes HTML files that refer to the applets themselves and runs them in a window. Figure 13.3 shows an applet molecule viewer that takes XYZ format molecule data and presents a three-dimensional model of the molecule.

Figure 13.3  The molecule viewer applet.

Observing the HTML file example1.html that is sent to the Appletviewer, you can see the format for entering applets into HTML pages.

<title>MoleculeViewer</title>
<hr>
<applet code=XYZApp.class width=300 height=300>
<param name=model value=models/HyaluronicAcid.xyz>
</applet>
<hr>
<a href=”XYZApp.java”<The source.</a>

The <applet …></applet> tag is used to tell the browser that it should load a Java applet. The <param …> tag is used to pass arguments to the applet at runtime. This is a different format than that used in the Alpha release of Java. At the end of the chapter is a fuller explanation of how to use the applet tag.

The Appletviewer has several options under the Applet menu option.

•  Restart. This command runs the loaded applet again.

•  Reload. This command reloads the applet from disk, and is useful if the .class file has changed since it was loaded.

•  Clone. This command creates a new Appletviewer window based upon the command-line arguments for the first.

•  Tag. This command shows the >applet< tag used in the HTML document to start the applet (see fig. 13.4).

Figure 13.4  The Tag dialog box in the Appletviewer.

•  Info. This command provides any information about the applet that is available (see fig. 13.5).

Figure 13.5  The Info dialog box in the Appletviewer.

•  Properties. This command enables the different network and security configurations to be set for the Appletviewer (see fig. 13.6). The first four entry boxes enable the Appletviewer to be run by using an HTTP proxy and firewall proxy. Both the proxy address and the port number are required. You should be able to get this information from your site administrator. The network access selector enables several levels of security, including no network access, only access to the applet’s host, and unrestricted access. The class access selector enables you to designate either restricted or unrestricted access to classes on the machine.

Figure 13.6  The Properties dialog box in the Appletviewer.

Table 13.3 indicates the meanings of the different security modes in terms of which Java programs can be loaded into the system.

The Appletviewer is a rudimentary tool as far as HTML content goes. It does nothing but display the Java applet itself. For testing applets, this is enough. Java applets, however, will be only one part of an overall web page, so it is important to see how an applet will fit in with the rest of an HTML document. In this case, a full-fledged web browser must be used, such as Netscape or HotJava.