Most Read This Week
By: Israel Hilerio
Jan. 1, 1998 12:00 AM
One of the primary reasons for the success of Java has been its robust dynamic class loading mechanism. The Java Virtual Machine ClassLoader is a mechanism that Java uses to load classes at runtime. Techniques to take advantage of Java's dynamic nature and the interactive nature of the Web usually create a spark of interest in the Java community.
This article leads the reader through the development of a new Java ClassLoader mechanism that leverages the Web for downloading Java classes. It begins with an overview of the Java ClassLoader mechanism, followed by an examination of how Java's ClassLoader can be extended to download Java classes from multiple Web servers to be used by a single Java application. This will allow users to develop applications that download behavior dynamically and extend their functionality on the fly using the Web.
The Mechanics of the Java ClassLoader
Another important activity of the ClassLoader is to link a Class. Linking takes a binary class and incorporates it into the Java Virtual Machine Runtime. This allows a class to be executed. There are three distinct operations involved when linking:
Verification ensures that the binary representation of a class maps to a valid operation, the instructions are type safe and the integrity of the Java Virtual Machine is not violated. Preparation initializes the static fields (both variables and constants) of a class with default values, and checks for abstract method consistency between classes. The resolution of symbolic references is used to verify the correctness of a reference (method signature verification, field signature verification, etc.) and substitute symbols with direct reference.
The default ClassLoader can be extended to define specific properties for loading Java classes. Some of the properties that can be defined are:
Developers can create their own ClassLoaders by extending the ClassLoader abstract class. The ClassLoader abstract class contains the following methods. For a detailed explanation of the ClassLoader abstract class refer to "The Java Class Libraries An Annotated Reference" (Chan and Lee, Addison Wesley, 1997).
The next section provides an example of a new ClassLoader, called the URLClassLoader, that extends the ClassLoader abstract class and leverages the Internet and Web browser to download Java classes into Java applications.
Unlike regular ClassLoader mechanisms which are file-based, the URLClassLoader requires a URL string in order to identify the location from where to download the class bytecodes. An example of a URL String is given below:
This String tells the ClassLoader to download a class call texteditor.class from the machine www.motorservice.com in the directory called java_classes.
The URLClassLoader is responsible for downloading the bytecodes from the URL location, instantiating a Class object from the downloaded bytecodes and caching the downloaded Class object for future use. These operations take place outside of the loadClass() method. The loadClass() method is called whenever an object is instantiated from the cached generated Class object using the newInstance() method on the Class class. We have chosen to download bytecodes and to process all of the class information outside of the loadClass() method because the URL information associated with the class name is not contained in the input parameters of the loadClass method. The caching policy may vary between ClassLoader implementations but the idea is the same, viz., to minimize the amount of time you go the network to access a class.
Applications of the URLClassLoader
URLClass Loader Trigger
The texteditor.class is a Java application that extends the Frame class. The trigger application downloads this type of application over the Internet and executes them. This trigger environment acts as a runtime shell for Java programs. The advantage of having the trigger environment executing the various Java applications is that it can act as a task manager by suspending or stopping the execution of the spawned programs. The user could extend this program to allow components of one application to communicate and interact with components of a second application.
There are two classes associated with the trigger environment, trigger and URLClassLoader. Figure 1 shows the class diagrams of the two classes. The trigger class is responsible for providing the URLClassLoader with the desired Java application to be downloaded. Also, it is responsible for creating an instance of the downloaded Java application class and for starting its execution by calling the main() method on the class. The URLClassLoader is responsible for downloading the bytecodes associated with the URL string and for linking the downloaded Java application class with the running JVM process.
Figure 2 shows the collaboration diagrams for executing a Java Application downloaded over the Web.
The trigger environment provides a simple application that allows a user to enter a URL with a Java application class. In order for the Java application class to be downloadable it must be contained in a Web server directory. Figure 3 shows the trigger environment application screen.
The method registerJavaClass() creates a URL input stream and downloads the byte codes via this mechanism. This is the first method called whenever the "Execute Java Application" button is pressed. The string typed inside the textfield is passed to this method.
// Create URL Stream
// Open URL Stream
// Open URL Stream
// Download byte codes from URL Stream
Also, the registerJavaClass() method creates a Class from the downloaded byte array.
// Create class from byte code
The method createClassFromByteCodes() creates a class by calling the defineClass() method on the default ClassLoader. In addition, this method is responsible for linking the created class object with the JVM runtime process. Once the class object has been linked it caches the object inside of a Hashtable (see Listing 1).
The loadClass() method gets executed whenever the class is being instantiated. This method checks the local java.class.path system property first to load the class locally. It checks the Hashtable cache if it can not find the class locally. If the class being instantiated has not been loaded it proceeds by trying to download the class from the last accessed Web site location (see Listing 2).
If the class being instantiated is not cached, the URLClassLoader attempts to download the requested class from the Web using the last accessed Web site. Fetching the class from the network is done by reconstructing a URL path to the requested class name (see Listing 3).
After the Java application class has been registered by the ClassLoader and instantiated by the trigger class, we use reflection to invoke the static main method inside the Java application. Since we are downloading Java applications over the Web, we expect the applications to contain a main() method. We search the Java class for a main(String) method and once we find it we execute the method (see Listing 4).
For a copy of the complete and working trigger program source code, please refer to Listing 5 and Listing 6. An additional enhancement that can be made to the trigger environment application is to persist the Hashtable object. This would allow the permanent caching of downloaded Java applications. However, the drawback to this approach is that as new releases of the applications are stored on Web servers you won't be able to use the new applications.
Reader Feedback: Page 1 of 1
Subscribe to the World's Most Powerful Newsletters
Today's Top Reads