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 _______________________________________________ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
