This is the mail archive of the
mailing list for the Mauve project.
RE: ClassLoader.findLoadedClass (was: ServiceFactory)
- From: "David Holmes" <dholmes at dltech dot com dot au>
- To: "Robert Lougher" <robert_lougher at hotmail dot com>
- Cc: <classpath at gnu dot org>, <mauve-discuss at sources dot redhat dot com>
- Date: Thu, 25 Mar 2004 09:58:01 +1000
- Subject: RE: ClassLoader.findLoadedClass (was: ServiceFactory)
- Xantivirus: This e-mail has been scanned for viruses via the Connexus Internet Service
Robert Lougher wrote:
> Yes, I agree (but see my comment below). >
> A pure Java "reference" implementation won't work. At the Java level
> VMClassLoader can only keep track of classes defined by a loader (when it
> calls VMClassLoader.defineClass). A call back will be needed so
> that the VM can record a loader as an initiating loader for a class.
Well you don't need an explicit callback as that's likely to be VM specific.
The VM can directly access the Java-level hashtable(s) if it needs to using
JNI or whatever means that particular VM has. The only thing you need in the
reference implementation is a comment saying that the VM must keep the
tables up to date.
That said, I don't see much value in a "reference implementation" for this