# 2 questions regarding class loaders

Alan Greenspan (alan@hi.com)
Thu, 29 Jul 1999 13:02:53 -0400

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: =?iso-8859-1?Q?G=FCnter?= Quintus: "With Netscape's signtool selfsigned applet doesn't work with Java plugin"
- Previous message: sajanjoseph: "security query"

    From: "Alan Greenspan" <alan@hi.com>

    To: <java-security@java.sun.com>

    Subject: 2 questions regarding class loaders

    Date: Thu, 29 Jul 1999 13:02:53 -0400

The JDK1.2 Security spec defines the class resolution algorithm (section
5.4). Excerpt follows:

"We have seen the delegation algorithm earlier. But, given the name of any
class, which class loader do we start with in trying to load the class? The
rules for determining the class loader are the following:

* When loading the first class of an application, a new instance of the
URLClassLoader is used.
* When loading the first class of an applet, a new instance of the
AppletClassLoader is used.
* When java.lang.Class.ForName is directly called, the primordial class
loader is used.
* If the request to load a class is triggered by a reference to it from
an
existing class, the class loader for the existing class is asked to load the
class."

Questions are:

1. How does the Thread context ClassLoader fit into this algorithm? Does
it apply to the last bullet? That is, is it in fact considered "the class
loader for the existing class" even though it may not have been the
ClassLoader which loaded the class?

2. I wish to create a ClassLoader instance (hopefully just using
URLClassLoader) that will be used to load a set of classes which cannot have
access to any classes in the containing application (this is for EJB
implementation). Of course, the system classes (java, javax) must be
accessible to the loaded classes. If I specifiy a null ClassLoader as the
parent ClassLoader to URLClassLoader.newInstance, I imagine that this makes
the boostrap (primordial??) ClassLoader the parent. The question is what
classes are loaded by this ClassLoader? Will it include just the system
classes or also those classes on the application's classpath? If it
includes classes on the application classpath, is there a way to specify a
parent ClassLoader that only loads the system classes?

What's a little confusing about the algorithm, is that section 5.2 seems to
indicate that the primordial class loader loads the system classes and
bootstraps the application ClassLoader. But, bullet 3 indicates that the
primordial class loader is used when using Class.forName. Since
Class.forName will find classes on the application classpath, this would
indicate that the primordial class loader has access to the classpath too.

Thanks in advance,
Alan

- Next message: =?iso-8859-1?Q?G=FCnter?= Quintus: "With Netscape's signtool selfsigned applet doesn't work with Java plugin"
- Previous message: sajanjoseph: "security query"