-
Bug
-
Resolution: Fixed
-
P3
-
None
-
7u15
-
linux
FULL PRODUCT VERSION :
java version "1.7.0_15"
Java(TM) SE Runtime Environment (build 1.7.0_15-b33)
Java HotSpot(TM) 64-Bit Server VM (build 23.7-b01, mixed mode)
ADDITIONAL OS VERSION INFORMATION :
I confirmed this problem on OSX 10.8.4 but the original bug on bug.oraclecorp.com (17437704) was reported for OS = Generic
A DESCRIPTION OF THE PROBLEM :
While this problem is more likely in a JavaEE application server, it would not be too difficult to write a reproducer in Java SE.
In an application server, isolation between applications is achieved by using application-specific class loaders to load each application resources. This isolation cannot be achieved for package-info because the first mypackage.package-info is cached by the Package class.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Define two versions of library containing mypackage.Foo and mypackage.page-info: one page-info with and the other without annotations.
An application has two URLClassLoaders each pointing to a different versions of he library.
Load Foo from the first ClassLoader and execute the following:
Foo.class.getPackage().getAnnotations().
Repeat with the second ClassLoader
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
You should expect no annotations in the first case, bug annotations in the second.
ACTUAL -
No annotations are returned in both the first and the second case because Foo.class.getPackage returned the same results for both class loaders.
Package caches Packages in the static pkgs map against the package name. In turn each Package caches package-info. Therefore it is not possible to get the annotations of a newer package-info with the Package APIs.
While it is possible to override ClassLoader.getPackage(..., it is not possible to create suitable Package instances.
REPRODUCIBILITY :
This bug can be reproduced always.
CUSTOMER SUBMITTED WORKAROUND :
A possible workaround is to load the new package-info with Class.forName. Then the annotations can be read directly from package-info. However, this is not possible when using libraries that use the Package APIs to get at the annotations. The work around would have to be used by many different library providers. I think it is better to fix that at the JDK level.
java version "1.7.0_15"
Java(TM) SE Runtime Environment (build 1.7.0_15-b33)
Java HotSpot(TM) 64-Bit Server VM (build 23.7-b01, mixed mode)
ADDITIONAL OS VERSION INFORMATION :
I confirmed this problem on OSX 10.8.4 but the original bug on bug.oraclecorp.com (17437704) was reported for OS = Generic
A DESCRIPTION OF THE PROBLEM :
While this problem is more likely in a JavaEE application server, it would not be too difficult to write a reproducer in Java SE.
In an application server, isolation between applications is achieved by using application-specific class loaders to load each application resources. This isolation cannot be achieved for package-info because the first mypackage.package-info is cached by the Package class.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Define two versions of library containing mypackage.Foo and mypackage.page-info: one page-info with and the other without annotations.
An application has two URLClassLoaders each pointing to a different versions of he library.
Load Foo from the first ClassLoader and execute the following:
Foo.class.getPackage().getAnnotations().
Repeat with the second ClassLoader
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
You should expect no annotations in the first case, bug annotations in the second.
ACTUAL -
No annotations are returned in both the first and the second case because Foo.class.getPackage returned the same results for both class loaders.
Package caches Packages in the static pkgs map against the package name. In turn each Package caches package-info. Therefore it is not possible to get the annotations of a newer package-info with the Package APIs.
While it is possible to override ClassLoader.getPackage(..., it is not possible to create suitable Package instances.
REPRODUCIBILITY :
This bug can be reproduced always.
CUSTOMER SUBMITTED WORKAROUND :
A possible workaround is to load the new package-info with Class.forName. Then the annotations can be read directly from package-info. However, this is not possible when using libraries that use the Package APIs to get at the annotations. The work around would have to be used by many different library providers. I think it is better to fix that at the JDK level.