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)

Interesting -- that's a documentation change between 1.3 and 1.4. In the specs for 1.3 it simply says:

protected final Class findLoadedClass(String name)
"Finds the class with the given name if it had been previously loaded through this class loader."

Which is suitably vague enough for several interpretations. Pragmatically, a class loader must keep track of the classes defined by itself so it doesn't try to define them again. This appears to be Classpaths'interpretation.

However, as Sascha points out, 1.4's explicitly says it should return classes _recorded by the virtual machine_ as initiated by the loader. Strictly, this doesn't mean all classes initiated by the loader, just the ones recorded by the VM. As I said, if loadClass is called implicitly by the VM it's recorded as an initiating loader, but not if loadClass is called explicitly by the programmer. The JDK is therefore correct, as loadClass was called explicitly.

In fact, nowhere in the documentation does it say that calling loadClass on a class loader makes it an initiating loader of the returned class!

The bad news is that Classpath (at least 0.07) is wrong according to the new documentation. It won't handle classes recorded by the VM as being initiated by it. Perhaps it should be moved into the VM class, so that a VM can do it natively using its internal class tables? (Alternatively, a VM can implement it as a call back to record it as an initiating loader).


----Original Message Follows----
From: Sascha Brawer <>
To: David Holmes <>, Chris Gray <>, Andrew Haley <>, Robert Lougher <>
CC: GNU Classpath <>, <>
Subject: Re: ClassLoader.findLoadedClass (was: ServiceFactory)
Date: Mon, 22 Mar 2004 10:15:54 +0100

Robert Lougher <> 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.

-- Sascha

Sascha Brawer,,

Express yourself with cool new emoticons

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