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

[Claes Redestad]

On 10/23/2014 02:54 AM, Mandy Chung wrote:
>
> On 10/22/2014 4:58 PM, Claes Redestad wrote:
>>
>>>
>>> This test uses a special class loader that delegates to null class 
>>> loader only.  Since you have the verification in place, it'd be good 
>>> to also call Package.getPackage and Package.getPackages to verify 
>>> that the same "package2" instance is returned.  As a sanity check, 
>>> you could check "java.lang" package must be present.
>>
>> I've added some sanity checks as suggested. Sadly, it seems that 
>> since the application classloader will define and load package2 first 
>> in this test, there'll always be a Package defined in the 
>> ClassLoader.pkgs that will mask the Package instance in Package.pkgs 
>> when retrieved via the public methods in Package. 
>
> Can you remove package2/Class2.class after you create the jar files?

Sorry for the confusion. I realized I did some of my test development on 
an unpatched JDK and got caught up in a subtle issue. Prior to the 
changes proposed, calling into Package.getSystemPackages() actually 
created new Package objects on each call(!!), breaking the assumption 
that only one Package object will ever be defined.

The proposed patch ensures we don't create new objects and that only one 
Package object can ever be created for a system package. This bug(?) was 
partially hidden by the fact that calling Package.getPackage() cached 
Package objects in the ClassLoader package maps, thus subsequent calls 
to Package.getPackages() would provide identical objects on subsequent 
calls. I've updated the test to verify Package identity (which it fails 
to do on an unpatched JDK).

>
>> If JDK-8061804 is resolved, we could change to check for identity in 
>> the Package.getPackages() case, which would improve the specificness 
>> of the test... For now, perhaps we could trick things in this test 
>> and put our dummy class into java.lang in our test here and ensure 
>> that the package retrieved is identical. Worth the hassle?
>
> What I meant is to check if the returned Package contains "java.lang" 
> package that always exists in the system packages. You don't need to 
> put a dummy class in java.lang to get "java.lang" Package since it 
> must be defined in the running VM. e.g. you can refactor line 169-176 
> to a findPackage method that returns Package matching the given 
> package name such that in line 164 you can call 
> findPackage("java.lang") that should return non-null.
>

http://cr.openjdk.java.net/~redestad/8060130/webrev.10

/Claes