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

[Mandy Chung]

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