On Fri, 19 Sep 2003 17:20:05 +0200 Mark Wielaard <[EMAIL PROTECTED]> 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 _______________________________________________ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe