JDK-8061804 : Re-examine Package of the same name allowed from ClassLoader.getPackages
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.lang:class_loading
  • Priority: P4
  • Status: Closed
  • Resolution: Other
  • OS: generic
  • CPU: generic
  • Submitted: 2014-10-22
  • Updated: 2016-03-23
  • Resolved: 2016-03-23
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 9
9Resolved
Related Reports
Relates :  
JDK-4841786 - (cl) flaw in ClassLoader getPackage/definePackage API
Relates :  
JDK-8060130 - Simplify the synchronization of defining and getting java.lang.Package
Relates :  
JDK-4302423 - class loaders should support "local" creation of Package objects
Description
Some issues with the current implementations were brought up during review of 8060130: 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-October/029085.html

Currently there's no possibility of preventing name collisions of packages defined in different classloaders, e.g., a Package can be defined in an ancestral classloader at any time (or in a child classloader as the result of a race), while ClassLoader.getPackages effectively hides packages defined in ancestral classloaders when there are name collisions with packages defined in the current classloader. 

The most straightforward solution seems to be to return all distinct packages, regardless of name uniqueness, as suggested by Mandy Chung (http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-October/029146.html).

It would also seem that the restriction on package definition in child classloaders should be loosened so that we only check the locally defined packages in ClassLoader.definePackage.
Comments
Package API has been updated in jdk-9+111 and this issue has been resolved.
23-03-2016
The following API change has been integrated in jdk-9+111 as part of the first integration of JEP 261 [1]. ClassLoader::definePackage defines a Package object unique within this ClassLoader. It no longer walks the class loader hierarchy to check for a duplicated package defined in an ancestor class loader. This addresses the flaw as described in JDK-4841786. Package objects are automatically defined when a ClassLoader defines a class and the Package object is not yet defined. In other words, Class::getPackage is guaranteed to return a non-null Package object except for array types, primitive types or void. A ClassLoader can explicitly define a Package object via ClassLoader::definePackage but that is not necessarily unless it wishes to define the Package with specific versioning information (see Package class specification). Package::getPackage(String name) and ClassLoader::getPackage(String name) are deprecated since Package objects are now defined by each class loader and looking up the class loader hierarchy may return an unexpected Package object. A more robust approach is to call ClassLoader::getDefinedPackage(String name). Package::getPackages and ClassLoader::getPackages will return all Packages defined by a ClassLoader and its ancestors. The returned array may contain more than one Package objects of the same name but defined by different ClassLoader. A new ClassLoader::getDefinedPackages method can be used to find all Packages defined by this class loader. [1] http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/b2a69d66dc65
23-03-2016