why is VM calling ClassLoader.loadClassInternal
twisti at complang.tuwien.ac.at
Wed Aug 29 02:11:07 PDT 2007
On Wed, 2007-08-29 at 19:03 +1000, David Holmes - Sun Microsystems
> 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
> 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).
Thanks for the explanation, I see the point. I will adopt that.
Compatibility is a pain :-)
More information about the hotspot-runtime-dev