RFR: 8060130: Simplify the synchronization of defining and getting java.lang.Package

[Bernd Eckenfels]

Hello Peter,

Am Fri, 24 Oct 2014 18:27:38 +0200
schrieb Peter Levart <peter.levart at gmail.com>:

> > One option for solving that in a still performant (lockless on hot
> > path) way would be a "ConcurrentSet" of package names used for the
> > initial decision if the hierachy needs traversed (and why may
> > define a package). With a set of strings it would not keep the
> > packages alive so it can be global. Not sure if it would need a
> > cleanup mechanism.. hmm.

> As it is perfectly legal for two unrelated classloaders (for example 
> peers sharing common parent) to each define it's own distinct class
> with the same name (imagine two J2EE apps each using it's own version
> of the same library bundled with them), so should two unrelated
> classloaders be able to define two distinct Packages with same name -
> and they can do that.

Yes, the set is only about determine with an atomic operation if you
need to traverse the tree or not. So for the case that a package is
homed by a single class loader, that class loader will make an entry
into the set (and suceed) and then does not need to do more parent
traversal. All other class loaders will see there is already the
package name reserved, and then they will need to coordinate with their
parents.

But its just an idea after inspecting the changes, not a real analysis
of all usage models. Maybe it is enough to do it for sealed packages.

Gruss
Bernd



 Standard delegation model makes sure that a
> class with a particular name can only be defined by one classloader
> in the delegation chain from initiating to the bootstrap classloader,
> but not all classloaders follow this rule (for example WAR
> classloader in web containers). Packages also "wish" to follow this
> rule, but fail, since the existence of a package is established only
> when 1st class from that package is loaded. Something similar is
> achieved by making packages "sealed", but not all packages are
> sealed, and I think that even distinct "sealed" packages with same
> name can exist in unrelated classloaders. So the most consistent
> thing to do would be to allow each classloader to define it's own
> packages (unless ancestors define a sealed package with same name)
> and to consistently return the Package defined by the Class' defining
> classloader from the Class.getPackage() method.
> ClassLoader.getPackages() method should then return a concatenation
> of defined packages from the invoked classloader up through ancestors
> to the bootstrap classloader and this list may contain Packages with
> non-unique names.
> 
> Regards, Peter
> 
>