Class loaders are the gatekeepers of the JVM, controlling what bytecode may be loaded and what should be rejected. As such they have a number of responsibilities:
1. To separate name spaces, thus preventing intentional and unintentional code corruption and limiting name clash problems to class files from one source.
2. To protect the boundaries of the core Java class packages (trusted classes) by refusing to load classes into these restricted packages.
3. Starting in Java 2, establish the protection domain (set of permissions) for a loaded class. This is the basis for run-time authorization checking for access to resources.
4. To enforce a search order that will prevent core and local classes from being replaced by classes from less trusted sources.
The class loader has another, useful, side effect. By controlling how the JVM loads code, all platform-specific file I/O is channelled through one part of the JVM, thus making porting the JVM to different platforms a much simpler task. Let’s look a little more closely at these responsibilities and why they are necessary.
First, Java code can be loaded from a number of different sources. Some of the more common sources are:
• The trusted core classes that ship with the JVM (java.lang.*, java.applet.* etc.)
• Any installed JVM extensions 146 Java 2 Network Security
• Classes stored in the local file system (usually found using the CLASSPATH system environment variable)
• Classes retrieved from external sources such as from a Web server Clearly, we would not want to overwrite a trusted JVM class with an identically named class from a Web server since this would undermine the entire Java security model. For instance, the SecurityManager class is responsible for a large part of the JVM run-time security and is a trusted local class; consider
what would happen to security if the SecurityManager could be replaced by a class loaded from a remote site. The class loader must therefore ensure that trusted local classes are loaded in preference to remote classes where a name clash occurs.
Secondly, where classes are loaded from Web servers, it is possible that there could be a deliberate or unintentional collision of names (although the Sun Java naming conventions exist to prevent unintentional name collisions). If two versions of a class exist and are used by different applets from different
Web sites, then the JVM, through the auspices of the class loader, must ensure that the two classes can coexist without any possibility of confusion occurring.
The class loader must protect the boundaries of the trusted class packages.The core Java class libraries that ship with the JVM reside in a series of packages. Within the Java programming language, it is possible to give special access privileges to classes that reside in the same package; thus, a class which is part of the java.lang package, for instance, has access to methods and fields within other classes in the java.lang package which are not accessible to classes outside of this package.
If it were possible for a programmer to add his or her own classes to the java.lang package, then those classes would also have privileged access to the core classes. This would be an exposure of the JVM and consequently must not be allowed. The class loader must therefore ensure that classes cannot be dynamically added to the various core language packages.
The JVM may have many class loaders operating at any point in time, each of which is responsible for locating and loading classes from different sources.
