[kaffe] loadClass() vs. loadClass()
Helmer Krämer
hkraemer@freenet.de
Fri Sep 19 09:33:02 2003
On Fri, 19 Sep 2003 17:20:05 +0200
Mark Wielaard <mark@klomp.org> wrote:
> Hi,
>
> On Fri, 2003-09-19 at 16:23, Helmer Krämer wrote:
> > Whenever kaffe has to load some class
> > using a user defined loader, it invokes the two parameter
> > form of loadClass.
> > [...]
> > The simple and quick fix would be to modify kaffe so
> > it calls the loadClass(String) method of a user defined
> > class loader instead of the loadClass(String, boolean)
> > one. In theory, this should not break existing code since
> > loadClass(String) simply calls the other method. I don't
> > know whether this is the right way to fix this, though.
>
> I think this is the correct fix. See:
> http://java.sun.com/docs/books/vmspec/2nd-edition/html/ConstantPool.doc.html#79448
>
> 1 Since JDK release 1.1 the Java virtual machine invokes the
> loadClass method of a class loader in order to cause it to load
> a class or interface. The argument to loadClass is the name of
> the class or interface to be loaded. There is also a
> two-argument version of the loadClass method. The second
> argument is a boolean that indicates whether the class or
> interface is to be linked or not. Only the two-argument version
> was supplied in JDK release 1.0.2, and the Java virtual machine
> relied on it to link the loaded class or interface. From JDK
> release 1.1 onward, the Java virtual machine links the class or
> interface directly, without relying on the class loader.
>
> You should also call the one argument ClassLoader.loadClass(String)
> method for Class.forName(), but I cannot quickly find where in the spec
> this is defined.
Could this probably help with the problem about loading
classes during verification, too? One of the problems
was that we thought we couldn't predict the state of a
class that's returned by a user class loader, but this
paragraph seems to define this, doesn't it ?
Regards,
Helmer