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
