Archie Cobbs wrote: > 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?
Sounds consistent and correct to me. > 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? As findLoadedClass is a final method in ClassLoader I consider its implementation part of the VM - as long as it and other parts of the VM use the same lookup table you can do whatever you like here. That said it seems to me that the lookup table defined in ClassLoader should be moved to VMClassLoader. That way we would have: ClassLoader.findLoadedClass(n) calls VMClassLoader.findLoadedClass(this, n) and ClassLoader.defineClass calls VMClassLoader.defineClass(this, ...) and VMClassLoader.defineClass can then update the lookup table however it is implemented in that VM. VMClassLoader can define a default mechanism using hashtables or just leave things native. Or in simple words: move the lookup table out of ClassLoader into VMClassLoader. David Holmes _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
