3.6. Miscellaneous Class Loading TopicsThere are a few details that we haven't yet covered. These details are not directly related to the security aspects of the class loader, which is why we've saved them until now. If you're interested in the complete details of the class loader, we'll fill in the last few topics here. 3.6.1. DelegationBeginning with Java 1.2, class loading follows a delegation model. This new model permits a class loader to be instantiated with this constructor:
You'll notice that we used delegation in all of our examples. This is pretty much a requirement: when the virtual machine starts, it creates a URL class loader that is based on the directories and JAR files present in your CLASSPATH. That class loader is the class loader that will be used to load the first class in your application (i.e., the JavaRunner class in our example). That URL class loader is the only class loader that knows about the CLASSPATH. If the application will reference any other classes that are part of the CLASSPATH, you will be unable to find them unless you use the delegation model of class loading: the JavaRunner loader will first ask the URL class loader to load the class. If the class is on the CLASSPATH, the URL class loader will succeed; otherwise, the Java-Runner loader will end up loading the class itself. This logic is built into the loadClass() method; you do not need to concern yourself with it at a programming level, but it is the reason why you must use delegation. This URL class loader is known as the system class loader, and it may be retrieved via the following method:
Hence, to set up a delegation class loader, you can use this call: Class Definitionjrl = new JavaRunnerLoader(ClassLoader.getSystemClassLoader()) instead of the methods we showed earlier. 3.6.2. Loading ResourcesA class loader can load not only classes, but any arbitrary resource: an audio file, an image file, or anything else. Instead of calling the loadClass() method, a resource is obtained by invoking one of these methods:
3.6.3. Loading LibrariesIn 1.2, a new method exists in the ClassLoader class:
This method is used by the System.loadLibrary() method to determine the directory in which the native library in question should be found. If this method returns null (the default), the native library must be in one of the directories specified by either the java.library.path or java.sys.library.path property; typically, these properties are set in a platform-specific way (e.g., from the LD_LIBRARY_PATH on Solaris or the PATH on Windows). That mimics the behavior that applies in 1.1 and earlier releases. However, a 1.2 custom class loader can override that policy and require that libraries be found in some application-defined location. This prevents a user from overriding the runtime environment to specify an alternate location for that library, which offers a slight security advantage. Note that if the user can write to the hardwired directory where the library lives, this advantage no longer exists: the user can simply overwrite the existing library instead of changing an environment variable to point to another library; the end result is the same. Copyright © 2001 O'Reilly & Associates. All rights reserved. |
|