> From: Godmar Back [mailto:[EMAIL PROTECTED]]
>
> >
> > All right, the more I look at the code moving to 1.2, the
> more I think the
> > best thing to do is to create a SystemClassLoader, a ClassLoader that
> > delegates to the VM for the dirty work. It would mean that
> absolutely no
> > classes would ever have getClassLoader() return null. There
> are bootstrap
> > problems, but nothing that can't be handled. Even
> SystemClassLoader would
> > have the instance of SystemClassLoader set as its class loader
> (the VM would
> > retroactively add all classes it loaded during bootstrap into the
> > SystemClassLoader).
> > With JDK 1.2, apparently you can set your own ClassLoader
> to be the system
> > class loader anyway. That means that only primordial classes
> like Thread
> > and Class and Object would have null classloaders. This system just
> > provides a default SystemClassLoader
> > It also makes everything simpler, cleaner and more uniform,
> additionally
> > making a lot of null pointer checks vanish.
> > I am sure there must be problems with doing this. Can
> anyone think of any?
> > Perhaps there are applications that depend on the null check for system
> > classloader? If there are such applications, why would they do so?
>
> There are such applications. Pretty much all applications that make
> non-trivial use of classloaders (Cornell's jkernel, for instance) and are
> written to the 1.1 API depend on getClassLoader() returning null for
> system classes. Remember that Sun changed the semantics from
> "returning null" to "may return a classloader or null" somewhere along
> the 1.1 -> 1.2 transition.
>
Yes, and I can't find any place in the docs that indicates that the system
classloader can be set to non-null.
> That said, I'd do what you suggest.
> We have had the same problem in Kaffe. For now, we decided to retain
> 1.1 compatibility (that is, return null), but as soon as we'll
> tackle 1.2,
> we'll have getClassLoader return a class loader for all classes.
>
Looking in the Security white paper (5.2), it suggests that the system class
loader is always null, and that null specifies the primordial class loader.
I don't know if we are supposed to consider the white papers canonical or
not.
Is it possible to set the root of the classloader tree somehow? If so, HOW
(I can't find an option to java)? And if you do that, do you make it simply
impossible to ever call the primordial class loader again? (Even the VM
itself should be using the system ClassLoader).
--John Keiser
