>
> 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.
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.
- Godmar
