JDK-8193889 : Class::getPackage() no longer returns null for a class in the unnamed package
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.lang:reflect
  • Affected Version: 9
  • Priority: P3
  • Status: Resolved
  • Resolution: Won't Fix
  • Submitted: 2017-12-20
  • Updated: 2017-12-20
  • Resolved: 2017-12-20
Related Reports
Relates :  
JDK-4841786 - (cl) flaw in ClassLoader getPackage/definePackage API
Relates :  
JDK-4302423 - class loaders should support "local" creation of Package objects
Relates :  
JDK-4302406 - Package sealing and creation of java.lang.Package objects is inconsistent.
Description
As reported here: http://java9.wtf/default-package/

Prior to 9, this method would return null for a class in the unnamed package. As of 9, it returns a Package object. This is an incompatible and undocumented change.
Comments
This is a behavioral change in 9. We will document this behavioral change in the release note.
20-12-2017
In 9, Class::getPackage returns a Package for a run-time package of this Class that addresses several design issues of java.lang.Package class (for example, two Class objects of the same package name defined by two class loaders may return the same Package object or may return null depending on the class loader implementation). For a class in the unnamed package or a class defined by a class loader that does not define a Package object via ClassLoader::definePackage, Class::getPackage returns a Package object in 9 whereas this method returns null prior to 9. This is a behavioral change that we should have documented in the JDK 9 release note. In 9, the following can be used determined if a class in the unnamed package: Class.getPackage().getName().isEmpty() or Class.getPackageName().isEmpty() Refer to the specification for Class::getPackage and Class::getPackageName for the exception when this class is an array, a primitive type or void.
20-12-2017