This is the mail archive of the mailing list for the Mauve project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Archie Cobbs      *        CTO, Awarix        *

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]