On 10/13/2014 2:04 AM, Peter Levart wrote:
On 10/13/2014 04:18 AM, David Holmes wrote:
Looking at definePackage it seems both old and new code have serious
race conditions due to a lack of atomicity when checking the
parent/system packages. A package of the same name could be defined
in the parent/system after definePackage has called getPackage - and
we then end up with two same named Packages in different loaders.
I don't know the history of the getPackage(s) methods. Since two
different class loaders can define a package of the same name and
effectively two separate runtime packages, it seems to me that
ClassLoader.getPackages should return all Package objects including the
duplicated names. Claes - do you mind filing a bug for it?
...
p1: package javax.swing
p2: package javax.swing, Java Platform API Specification, version 1.9
p3: package javax.swing, Java Platform API Specification, version 1.9
Now if the order of class loading is changed:
...
p1: package javax.swing, Java Platform API Specification, version 1.9
p2: package javax.swing, Java Platform API Specification, version 1.9
p3: package javax.swing, Java Platform API Specification, version 1.9
So reliable "sealed" packages can only exist if they are defined
in-advance or at least one class from a particular sealed package is
loaded by the authoritative ClassLoader before a child of that loader
is given a chance to load classes.
A: So perhaps, to support class-loading-order independent behaviour, a
descendant ClassLoader could be given a chance to define it's own
package although the ancestor has already defined one with the same
name, unless this is a sealed package of course.
B: A backwards-incompatible and more restrictive strategy could be to
prevent an ancestor ClassLoader from defining a Package if one of
descendants in the chain leading from initiating ClassLoader to the
ancestor already defines a package with the same name. This would not
prevent loading of such "conflicting" classes for the entire system,
but only for a particular code that happens to be defined by the
ClassLoader that (or it's ancestor) violates the constraint that a
descendant ClassLoader must not define classes in the package of the
same name as ancestor ClassLoader. It would prevent classes loaded by
a violating ClassLoader from accessing classes in sealed packages,
which might be enough to enforce intra-package access restrictions...
How does Jigsaw solve this puzzle?
java.lang.Package is not used at runtime. I think
ClassLoader.getPackage(s) method should be revisited whether it should
lookup its parent loader. I think your question concerns the runtime
package that is not effect by java.lang.Package.
Mandy
