Subpackages exist to allow code to be conveniently organized. They impose a restriction on class/interface naming (a class cannot have the same fully qualified name as a subpackage), but are otherwise no different than two unrelated packages.
The Java Language Specification defines what subpackages are in section 7.1, Package Members.
A subpackage is any package directly nested within another package. For instance, com.example.subpackage is a subpackage of com.example:
The members of a package are its subpackages and all the top level class types and top level interface types declared in all the compilation units of the package.
For example, in the Java SE Platform API:
- The package
java has subpackages awt, applet, io, lang, net, and util, but no compilation units.
- The package
java.awt has a subpackage named image, as well as a number of compilation units containing declarations of class and interface types.
Subpackages enforce naming constraints between subpackages and classes/interfaces within the package. Namely, a subpackage and a class/interface cannot share the same name within the same package:
A package may not contain two members of the same name, or a compile-time error results.
Here are some examples:
- Because the package
java.awt has a subpackage image, it cannot (and does not) contain a declaration of a class or interface type named image.
- If there is a package named
mouse and a member type Button in that package (which then might be referred to as mouse.Button), then there cannot be any package with the fully qualified name mouse.Button or mouse.Button.Click.
- If
com.nighthacks.java.jag is the fully qualified name of a type, then there cannot be any package whose fully qualified name is either com.nighthacks.java.jag or com.nighthacks.java.jag.scrabble.
The subpackage concept primarly exists for organizational purposes. The restriction against name conflicts is the only significance afforded to subpackages by the language:
The hierarchical naming structure for packages is intended to be convenient for organizing related packages in a conventional manner, but has no significance in itself other than the prohibition against a package having a subpackage with the same simple name as a top level type declared in that package.
For example, there is no special access relationship between a package named oliver and another package named oliver.twist, or between packages named evelyn.wood and evelyn.waugh. That is, the code in a package named oliver.twist has no better access to the types declared within package oliver than code in any other package.
