To execute byte code, verification is clearly part of the larger process that's undertaken by the VM. For instance, suppose a developer wants to execute a program that simply writes "hello world" to a standard output. He or she must take the following steps:

• Load the .class file into the VM.
• Link the byte code with the Java run-time environment.
• Verify the byte code.
• Allocate resources for run time.
• Resolve references.
• Initialize classes.
• Invoke the main method.

Through this whole process, the byte-code verifier's most important accomplishments are that it:

• Checks the format of the .class file.
• Protects against version skew.
• Checks for stack overflow.
• Checks for illegal data conversions.
• Checks instructions to ensure proper parameters on the stack.

THE ROLE OF THE CLASS LOADER
The class loader is the link between the outside world and the VM. All of the byte code that's brought into the VM must be done so under the auspices of a class loader. A default class loader forms part of the Java Development Kit (JDK). Users who write their own VM may eventually call the default class loader if they're unable to load a class using other class loaders.

To write a Java program, users are required to set an environment variable known as CLASSPATH. This variable is used by the default class loader to load trusted classes. The logic is that if classes are found under CLASSPATH, they must have been put there by the person who set this variable. Subsequently, the default class loader can trust those classes.

If there's a class that isn't listed in the CLASSPATH, a separate class loader must be provided to load it. The implication here is that the class loader is part of the class identity. For instance, browsers often use different class loaders to load classes from varied sources. Given that class loaders play a vital role in the loading of classes, the security manager must check to see if a class is allowed to create a class loader (FIG. 3). Put simply, two classes are of the same type only if they have the same fully qualified name (FQN) and are loaded by the same class loader.

The following statements depict some definitions of class-loader methods. While the bodies for these methods are too lengthy to be included here, they are available at www.ti.com/javasecurity.

The class Java.lang.classloader is an abstract class. From it, other class loaders can be subclassed. It is defined with the statement:

protected abstract class loadClass(String name, Boolean resolve)
throws ClassNotFoundException;

The following is an example of a class loader:

import Java.io.*;
import Java.net.*;
public final class URLClassLoader extends Classloader
{
Extend Java.lang.ClassLoader which is an abstract class
private String urlAsString;

The next string contains the location from which the class loader will load files. It could be a URL, such as www.foobar.edu. The location is set only once at the time that this class is instantiated:

protected URLClassLoader() throws MalformedException
{
this(null);
}

The constructor for this class takes no arguments:

public URLClassLoader(String urlStr) throws MalformedURLException
{
if (urlStr == null || urlStr.length() == 0)
throw MalformedURLException("No url provided.");
urlAsString = urlStr;
}

The constructor merely checks for the presence of a string and ensures that it has a non-zero length. If these conditions aren't met, the constructor throws a MalformedURLException:

public synchronized Class loadClass(String name, Boolean resolve)
throws Java.lang.ClassNotFound Exception
{
}

In the following statement, loadClass is the abstract method that must be implemented:

private byte[] readClassFile(String classFileName) throws
FileNotFoundException, IOException
{
}

In summary, the class loader does the following:

• It takes a name and produces a class object.
• The class loader subclasses from Java.lang.Classloader (an abstract class).
• It defines method loadClass after extending Classloader.
• It maintains separate namespaces.