RE: ClassLoader.findLoadedClass (was: ServiceFactory)

["David Holmes" <dholmes@dltech.com.au>]

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