[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-hotspot-runtime-dev
Subject:    why is VM calling ClassLoader.loadClassInternal
From:       twisti () complang ! tuwien ! ac ! at (Christian Thalinger)
Date:       2007-08-29 9:11:07
Message-ID: 1188378667.3716.8.camel () localhost ! localdomain
[Download RAW message or body]

On Wed, 2007-08-29 at 19:03 +1000, David Holmes - Sun Microsystems
wrote:
> 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).

Hi David!

Thanks for the explanation, I see the point.  I will adopt that.
Compatibility is a pain :-)

- twisti



[prev in list] [next in list] [prev in thread] [next in thread]