This is the mail archive of the
mauve-discuss@sources.redhat.com
mailing list for the Mauve project.
Re: ClassLoader.findLoadedClass (was: ServiceFactory)
- From: Archie Cobbs <archie at dellroad dot org>
- To: David Holmes <dholmes at dltech dot com dot au>
- Cc: Robert Lougher <robert_lougher at hotmail dot com>, brawer at dandelis dot ch, chris at kiffer dot eunet dot be, aph at redhat dot com, classpath at gnu dot org, mauve-discuss at sources dot redhat dot com
- Date: Tue, 23 Mar 2004 10:47:14 -0600 (CST)
- Subject: Re: ClassLoader.findLoadedClass (was: ServiceFactory)
David Holmes wrote:
> Allow me to take a walk through the spec here :)
This is all very interesting and making my brain hurt :-) I'm trying to
figure out now if the JC vm does the right thing. Hopefully this email
will not add to the confusion.
JC will record C in the (internal to the VM) initiated types table
associated with a class loader L if and only if:
(a) L is the defining loader for C (i.e., L.defineClass(C) was called); or
(b) L.loadClass(C) successfully returns after being called **from
within the VM itself** (e.g., as a result of the VM's trying
to resolve a symbolic reference).
So if another loader L2 delegates the loading of C to L, then L is not
marked as an initiating loader for C, as neither (a) nor (b) happens.
Is this consistent and/or correct with the current understanding?
Also: this discussion seems to imply that we require a native method
that findLoadedClass() can use to ask the VM to look for C in its internal
initiated types table associated with L.. is that correct?
At one time I remember concluding that to satisfy the specs, even though
the ClassLoader object may have a Hashtable of loaded classes or whatever,
the VM must have its own internal initiated types table associated with each
class loader. If this is true, then findLoadedClass() simply needs to look
into it - requiring a native method. I believe this is because the VM can't
rely on the ClassLoader implementation to do the right thing with respect
to not trying to load the same class twice.
Classpath has this:
protected final synchronized Class findLoadedClass(String name)
{
// NOTE: If the VM is keeping its own cache, it may make sense to have
// this method be native.
return (Class) loadedClasses.get(name);
}
Perhaps then the comment should be removed and this method made native
always?
Thanks,
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com