RE: A few small fixes

[Jeroen Frijters]

David Holmes wrote:
> > Jeroen Frijters wrote:
> > Calling ClassLoader.loadClass(String, boolean) from Class.forName is
> > incorrect and, more importantly, incompatible with Sun's
> > implementation, ...
> 
> Why is it incorrect to call loadClass(name, true)?

Because it isn't public. The fact that it happens to be accessible
because it is protected and Class happens to be in the same package as
ClassLoader doesn't mean it is right to call it. Plus, the fact that
loadClass(name) is public and non-final means that subclasses can
override it, so we need to call that to be compatible.

> Class.forName(String name, boolean init, ClassLoader cl) is required
> to "locate, load and link [the given class] using the given
> ClassLoader" and to initialize or not, depending on the init
> parameter.

True, but you do know that in most VMs "linking" is a no-op, right?

> ClassLoader.loadClass(String name, boolean resolve) is required to
> find and load the given class, and if found to resolve it, or not,
> depending on the resolve parameter.
> 
> Remembering that resolve means link, this means that the first part of
> Class.forName's job can be done by invoking: cl.loadClass(name, true);
> 
> 
> As for "compatibility" with Sun's implementation I am at a loss.
> First, I thought you classpath folk were supposed to remain untainted
> from internal knowledge of the Sun implementation. ;-)

This is *not* in internal implementation detail. I've written a custom
class loader and ran it under the Sun VM and observed the
Classloader.loadClass(name) being called from Class.forName().

> Second, in
> 1.4.1 Class.forName delegates to a native method, while loadClass
> implements the algorithm defined by its specification. So where is
> there any kind of compatability issue?

This isn't some random thing I dreamed up. I actually ran into this
problem while trying to get JBoss to run on IKVM. JBoss has a broken
custom class loader that overrides loadClass(name).

> The only potential problem with invoking a non-final method like
> loadClass is that you are relying on it being overriden correctly, so
> would have to be careful how you treated the returned class instance.
> But if that is a concern then forName should just use a native method
> or a VMxxx method - and neither the current code, nor the suggested
> patch seems to have this concern.

I assume you mean using JNI to call ClassLoader.loadClass(name)
non-virtually. As can be deduced from the above, Sun's doesn't do this,
so neither should we.

Regards,
Jeroen