Responsibilities of the Class Loader

if sm = null { int i = name.lastIndexOf.; if i = −1 { sm.checkPackageDefinitionname.substring0, i; } } return super.findClassname; }

6.3.4.5 Step 5: Read in the class bytes

The URL class loader performs this operation for you by consulting the URLs that were passed to its constructor. If you need to adjust the way in which the class bytes are read, you should use the SecureClassLoader class instead.

6.3.4.6 Step 6: Create the appropriate protection domain

The URL class loader will create a code source for each class based on the URL from which the class was loaded and the signers if any of the class. The permissions associated with this code source will be obtained by using the getPermissions method of the Policy class, which by default will return the permissions read in from the active policy files. In addition, the URL class loader will add additional permissions to that set: If the URL has a file protocol, it must specify a file permission that allows all files that descend from the URL path to be read. For example, if the URL is file:xyzclasses, then a file permission with a name of xyzclasses− and an action list of read will be added to the set of permissions. If the URL is a jar file file:xyzMyApp.jar, the name file permission will be the URL itself. • If the URL has an HTTP protocol, then a socket permission to connect to or accept from the host will be added. For example, if the URL is http:piccoloclasses, then a socket permission with a name of piccolo:1− and an action list of connect,accept will be added. • If you want to associate different permissions with the class, then you should override the getPermissions method. For example, if we wanted the above rules to apply and also allow the class to exit the virtual machine, wed use this code: protected PermissionCollection getPermissionsCodeSource codesource { PermissionCollection pc = super.getPermissionscodesource; pc.addnew RuntimePermissionexitVM; return pc; } We could completely change the permissions associated with the class bypassing the Policy class altogether by constructing a new permission collection in this method rather than calling super.getPermissions . The URL class loader will use whatever permissions are returned from this getPermissions method to define the protection domain that will be associated with the class.

6.3.4.7 Steps 7−8: Define the class, verify it, and resolve it

These steps are handled internally by the URL class loader.

6.3.5 Using the SecureClassLoader Class

If you need to load bytes from a source that is not a URL or from a URL for which you dont have a protocol handler, like FTP, then youll need to extend the SecureClassLoader class. A subclass is required because the constructors of this class are protected, and in any case you need to override the findClass method in order to load the class bytes. The subclass can call either of these constructors: protected SecureClassLoader protected SecureClassLoaderClassLoader parent Create a secure class loader. The parent argument will become the parent of this class loader; if none is provided, then the class loader that calls the constructor will be the parent class loader. The steps to use this class are exactly like the steps for the URLClassLoader class, except for step 5. To implement step 5, you must override the findClass method like this: protected Class findClassfinal String name throws ClassNotFoundException { First check if we have permission to access the package. You could remove these 7 lines to skip the optional step 4. SecurityManager sm = System.getSecurityManager ; if sm = null { int i = name.lastIndexOf.; if i = −1 { sm.checkPackageDefinitionname.substring0, i; } } Now read in the bytes and define the class try { return Class AccessController.doPrivileged new PrivilegedExceptionAction { public Object run throws ClassNotFoundException { byte[] buf = null; try { Acutally load the class bytes buf = readClassBytesname; } catch Exception e { throw new ClassNotFoundExceptionname, e; } Create an appropriate code source CodeSource cs = getCodeSourcename; Define the class return defineClassname, buf, 0, buf.length, cs; } } ; } catch java.security.PrivilegedActionException pae { throw ClassNotFoundException pae.getException ; } } The syntax of this method is complicated by the fact that we need to load the class bytes in a privileged block. Depending on your circumstances, that isnt strictly necessary, but its by far the most common case for class loaders. Say that your class loader loads class A from the database; that class is given minimal permissions. When that class references class B , the class loader will be asked to load class B and class A will be on the stack. When its time to load the new class bytes, we need to load them with the permissions of the class loader rather than the entire stack, which is why we use a privileged block. Notwithstanding, the try block has three operations: it loads the class bytes, it defines a code source for that class, and it calls the defineClass method to create the class. The first two of the operations are encapsulated in the readClassBytes and getCodeSource methods; these are methods that 108