This is the mail archive of the
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: <firstname.lastname@example.org>
Robert Lougher <email@example.com> wrote on Mon, 22 Mar 2004 09:
>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.
Sascha Brawer, firstname.lastname@example.org, http://www.dandelis.ch/people/brawer/