RE: [cp-patches] RFC: Class Loader patch to record classwithinitiating class loader

[Jeroen Frijters]

Mark Wielaard wrote:
> It looks like that is also what gcj and jamvm do already. 
> That is why I am surprised that we really need the double callbacks
> everywhere. Does that make the interface really more flexible?
> In the case of Class.forName() you mean that when we need to delegate
> to ClassLoader.loadClass() we need to register the initial class
loader
> explicitly because that class loader could load the class through
> delegation to one of its parents?

Exactly. Because of the broken "design" (really evolution) of
ClassLoader it cannot be done there, so the hook in Class.forName() is
definitely required (at least, I don't see any possible alternative).

> Even though there is that one exception I would make the
> VMClass.loadClass(), VMClass.loadArrayClass() and
> VMClassLoader.defineClass() (reference) methods do the registration
> themselves.

Apart from VMClass.loadClass() (which doesn't actually exist), I would
be fine with removing the additional registration calls and only doing
that for the scenario where Class.forName() directly invokes
ClassLoader.loadClass().

> That seems to me to make some things easier for 
> the runtime implementers that already do these things internally.

I don't think it matters that much either way, because multiple
"registrations" are harmless (other than that they're useless overhead
of course), but a cleaner interface would ultimately be better.

To sum up: Unless any of the VM implementers that rely on
ClassLoader.loadedClasses speak up, I'm going to write a new version of
my patch that is much simpler on the Classpath side and requires the VM
to do the right thing. OK?

Regards,
Jeroen