Class Loader Classes Implementing a Class Loader

beginning of the findClass method. Note that this step should take place after the parent class loader is queried rather than at the beginning of the operation as is done with the access check. No Sun−supplied class loader implements this step; it corresponds to the defineClassInPackage permission. The class file is read into an array of bytes. The mechanism by which the class loader reads the file and creates the byte array will vary depending on the class loader which, after all, is one of the points of having different class loaders. This occurs in the findClass method. 5. The appropriate protection domain is created for the class. This can come from the default security model i.e., from the policy files, and it can be augmented or even replaced by the class loader. Alternately, you can create a code source object and defer definition of the protection domain. This occurs in the findClass method. 6. Within the findClass method, a Class object is constructed from the bytecodes by calling the defineClass method. If you used a code source in step 6, the getPermissions method will be called to find the permissions associated with the code source. The defineClass method also ensures that the bytecodes are run through the bytecode verifier. 7. Before the class can be used, it must be resolved −− which is to say that any classes that it immediately references must also be found by this class loader. The set of classes that are immediately referenced contains any classes that the class extends as well as any classes used by the static initializers of the class. Note that classes that are used only as instance variables, method parameters, or local variables are not normally loaded in this phase: they are loaded when the class actually references them although certain compiler optimizations may require that these classes be loaded when the class is resolved. This step happens in the loadClass method. 8. In the next two sections, well see how this plays out in each of the class loader types. Note that we do not show how to subclass the ClassLoader class directly: all class loaders should subclass the SecureClassLoader class or its subclasses instead.

6.3.4 Using the URL Class Loader

If you want to use a custom class loader, the easiest route is to use the URL class loader. This limits the number of methods that you have to override. To construct an instance of this class, use one of the following constructors: public URLClassLoaderURL urls[] public URLClassLoaderURL urls[], ClassLoader parent Construct a class loader based on the given array of URLs. This class loader attempts to find a class by searching each URL in the order in which it appears in the array. The parent of this class loader will be the class loader passed to the constructor or, if one is not provided, the class loader of the class that is creating the URLClassLoader object. An instance of the URLClassLoader class may also be obtained via one of these methods: public static URLClassLoader newInstanceURL[] urls public static URLClassLoader newInstanceURL[] urls, ClassLoader parent Create and return a URL class loader. The difference between these methods and constructing a URL class loader directly is that the class loader returned from these methods will call the security managers checkPackageAccess method before it attempts to define a class. Only class loaders obtained this way will perform that optional step unless you write your own class loader to perform that step. Chapter 6. Java Class Loaders So a URL class loader that you construct directly will not implement step 1 in the list above, while one obtained from the newInstance method will. Neither implementation provides step 4 calling the checkPackageDefinition method of the security manager. We can construct a URL class loader like this: URL urls[] = new URL[2]; urls[0] = new URLhttp:piccolo.East~sdo; urls[1] = new URLfile:homeclassesLocalClasses.jar; ClassLoader parent = this.getClass.getClassLoader ; URLClassLoader ucl = new URLClassLoaderurls, parent; When we use this class loader to load the class com.sdo.Car , the class loader first attempts to load it via http:piccolo.East~sdocomsdoCar.class; if that fails, it looks for the class in the LocalClasses.jar file. This class loader is the basis of the class loader used by the command−line interpreter. In that case, the array of URLs is created based on the list of URLs that make up the classpath. To implement a URL class loader, we follow the steps listed before.

6.3.4.1 Step 1: Optionally call the checkPackageAccess method

If you need to modify other behavior of the URL class loader, then you cannot use the newInstance method. In that case, in order to use the checkPackageAccess method, you must override the loadClass method like this: public final synchronized Class loadClassString name, boolean resolve throws ClassNotFoundException { First check if we have permission to access the package. SecurityManager sm = System.getSecurityManager ; if sm = null { int i = name.lastIndexOf.; if i = −1 { sm.checkPackageAccessname.substring0, i; } } return super.loadClassname, resolve; }

6.3.4.2 Step 2: Use the previously−defined class, if available

The loadClass method of the ClassLoader class performs this operation for you, which is why weve called the super.loadClass method.

6.3.4.3 Step 3: Defer class loading to the parent

The loadClass method of the ClassLoader class performs this operation.

6.3.4.4 Step 4: Optionally call the checkPackageDefinition method

In order to call the checkPackageDefinition method, you must override the findClass method: protected Class findClassfinal String name throws ClassNotFoundException { First check if we have permission to access the package. SecurityManager sm = System.getSecurityManager ;