why is VM calling ClassLoader.loadClassInternal

[David Holmes - Sun Microsystems]

Christian,

The "magic" is that loadClassInternal is synchronized.

There's a very long and checkered history here. When the classloader 
architecture was re-worked in JDK 1.2 they should have made certain 
methods, like loadClass, final. But compatibility said they couldn't do 
that and instead it is recommended that loadClass not be overridden but 
instead findClass is overridden. This means the VM can't make 
assumptions about whether a classLoader correctly protects itself 
against concurrent loading. Hence loadClassInternal was made the private 
upcall made by the VM, so at least it was known that the call was 
synchronized.

For "well-behaved" classloaders that follow the delegation model 
correctly this works fine. For classloaders that don't do that ... well 
you'll see some very ugly and inexplicable code in there to try and 
accommodate them.

The classloader architecture is being re-visited for Java 7, in part to 
allow more flexible delegation structures that are anticipated for the 
Java module system (JSR 277) and superpackages (JSR 294).

Cheers,
David Holmes

Christian Thalinger said the following on 29/08/07 06:29 PM:
> Hi!
> 
> Can someone tell me why HotSpot calls ClassLoader.loadClassInternal
> instead of loadClass directly?  There's no magic in that method:
> 
>     // This method is invoked by the virtual machine to load a class.
>     private synchronized Class loadClassInternal(String name)
> 	throws ClassNotFoundException
>     {
> 	return loadClass(name);
>     }
> 
> Some magic hiden in HotSpot?
> 
> - twisti
>