Java Reference
In-Depth Information
ular compilation. The observability of compilation units in turn determines which packages
are observable, and which packages are in scope.
In simple implementations of the Java SE platform, packages and compilation units may
be stored in a local file system. Other implementations may store them using a distributed
file system or some form of database.
If a host system stores packages and compilation units in a database, then the database must
not impose the optional restrictions (§
7.6
) on compilation units permissible in file-based
implementations.
For example, a system that uses a database to store packages may not enforce a max-
imum of one public class or interface per compilation unit.
Systems that use a database must, however, provide an option to convert a program to a
form that obeys the restrictions, for purposes of export to file-based implementations.
As an extremely simple example of storing packages in a file system, all the packages
and source and binary code in a project might be stored in a single directory and
its subdirectories. Each immediate subdirectory of this directory would represent a
top level package, that is, one whose fully qualified name consists of a single simple
name. Each further level of subdirectory would represent a subpackage of the package
represented by the containing directory, and so on.
The directory might contain the following immediate subdirectories:
com
gls
jag
java
wnj
where directory
java
would contain the Java SE platform packages; the directories
jag
,
gls
, and
wnj
might contain packages that three of the authors of this specification cre-
ated for their personal use and to share with each other within this small group; and
the directory
com
would contain packages procured from companies that used the con-
ventions described in §
6.1
to generate unique names for their packages.
Continuing the example, the directory
java
would contain, among others, the following
subdirectories:
applet
awt
io
