why is VM calling ClassLoader.loadClassInternal
David Holmes - Sun Microsystems
David.Holmes at Sun.COM
Wed Aug 29 02:03:06 PDT 2007
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
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
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).
Christian Thalinger said the following on 29/08/07 06:29 PM:
> 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
More information about the hotspot-runtime-dev