This is the mail archive of the
mauve-discuss@sources.redhat.com
mailing list for the Mauve project.
Re: ClassLoader.findLoadedClass (was: ServiceFactory)
- From: Sascha Brawer <brawer at dandelis dot ch>
- To: David Holmes <dholmes at dltech dot com dot au>, Chris Gray<chris at kiffer dot eunet dot be>, Andrew Haley <aph at redhat dot com>, Robert Lougher<robert_lougher at hotmail dot com>
- Cc: GNU Classpath <classpath at gnu dot org>, <mauve-discuss at sources dot redhat dot com>
- Date: Mon, 22 Mar 2004 10:15:54 +0100
- Subject: Re: ClassLoader.findLoadedClass (was: ServiceFactory)
- References: <20040322081359.4021@smtp.mail.ch.easynet.net>
Robert Lougher <robert_lougher@hotmail.com> wrote on Mon, 22 Mar 2004 09:
03:12 +0000:
>However, in the explicit case, the initiator has been lost --
>defineClass only has the defining loader, and we don't have an "add
>initiating loader" call for use when we unwind. Even if findLoadedClass was
>native so it could use the VM class cache, the VM wouldn't know that, using
>your example, L1 initiated the load and would return null.
Does this mean that the API specification for ClassLoader.findLoadedClass
is incorrect? Or should it say that a VM may or may not record the fact that
some ClassLoader has initiated the loading of a class?
> protected final Class findLoadedClass(String?name)
>
> Returns the class with the given name if this loader has been recorded
> by the Java virtual machine as an initiating loader of a class with
> that name. Otherwise null is returned.
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/
ClassLoader.html#findLoadedClass(java.lang.String)
-- Sascha
Sascha Brawer, brawer@dandelis.ch, http://www.dandelis.ch/people/brawer/