On 10/23/2014 03:27 AM, Bernd Eckenfels wrote:
Am Wed, 22 Oct 2014 14:56:59 -0700
schrieb Mandy Chung <mandy.ch...@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
