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

[Peter Levart]

On 10/23/2014 03:27 AM, Bernd Eckenfels wrote:
> Am Wed, 22 Oct 2014 14:56:59 -0700
> schrieb Mandy Chung <mandy.chung at oracle.com>:
>> I guess your question is related to my comment about two class loaders
>> can define classes in a package of the same name (two different
>> runtime packages).  ClassLoader.getPackage(s) assumes there is only
>> one Package for each name in the class loader chain which seems wrong
>> to me. Claes has filed a bug to track this:
>>     https://bugs.openjdk.java.net/browse/JDK-8061804
> Yes, I think thats the same, Mandy.
>
> 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.
>
> Gruss
> Bernd
Hi Bernd,

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.
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