A package declaration appears within a compilation unit to indicate the package to which the compilation unit belongs. A compilation unit that has no package declaration is part of an unnamed package.
A package declaration in a compilation unit specifies the name (§6.2) of the package to which the compilation unit belongs.
PackageDeclaration:
package
PackageName;
The package name mentioned in a package declaration must be the fully qualified name (§6.7) of the package.
If a type named T is declared in a compilation unit of a package whose fully qualified name is P, then the fully qualified name of the type is P.
T; thus in the example:
package wnj.points; class Point { int x, y; }
the fully qualified name of class Point
is wnj.points.Point
.
A compilation unit that has no package declaration is part of an unnamed package. As an example, the compilation unit:
class FirstCall { public static void main(String[] args) { System.out.println("Mr. Watson, come here. " + "I want you."); } }
defines a very simple compilation unit as part of an unnamed package.
A Java system must support at least one unnamed package; it may support more than one unnamed package but is not required to do so. Which compilation units are in each unnamed package is determined by the host system.
In Java systems that use a hierarchical file system for storing packages, one typical strategy is to associate an unnamed package with each directory; only one unnamed package is available at a time, namely the one that is associated with the "current working directory." The precise meaning of "current working directory" depends on the host system.
Unnamed packages are provided by Java principally for convenience when developing small or temporary applications or when just beginning development.
Caution must be taken when using unnamed packages. It is possible for a compilation unit in a named package to import a type from an unnamed package, but the compiled version of this compilation unit will likely then work only when that particular unnamed package is "current." For this reason, it is strongly recommended that compilation units of named packages never import types from unnamed packages. It is also recommended that any type declared in an unnamed package not be declared public
, to keep them from accidentally being imported by a named package.
It is recommended that a Java system provide safeguards against unintended consequences in situations where compilation units of named packages import types from unnamed packages. One strategy is to provide a way to associate with each named package at most one unnamed package, and then to detect and warn about situations in which a named package is used by more than one unnamed package. It is specifically not required-indeed, it is strongly discouraged-for an implementation to support use of a named package by more than one unnamed package by maintaining multiple compiled versions of the named package.
Which top-level package names are in scope (§6.3, §6.5) is determined by conventions of the host system.
Package names never hide other names.
Whether access to members of a package is allowed is determined by the host system. The package java
should always be accessible, and its standard subpackages lang
, io
, and util
should always be accessible.
It is strongly recommended that the protections of a file system or database used to store Java programs be set to make all compilation units of a package available whenever any of the compilation units is available.