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?
Look at the docs for ClassLoader.getSystemClassLoader(). Says it returns
null if there is none. What if it never returned null?
--John Keiser
