📄 7.doc.html
字号:
<html>
<head>
<title>The Java Language Specification Packages</title>
</head>
<body BGCOLOR=#eeeeff text=#000000 LINK=#0000ff VLINK=#000077 ALINK=#ff0000>
<a href="index.html">Contents</a> | <a href="6.doc.html">Prev</a> | <a href="8.doc.html">Next</a> | <a href="j.index.doc1.html">Index</a>
<hr><br>
<a name="34412"></a>
<p><strong>
CHAPTER 7 </strong></p>
<a name="60384"></a>
<h1>Packages</h1>
<hr><p>
<a name="61541"></a>
Java programs are organized as sets of packages. Each package has its own set
of names for types, which helps to prevent name conflicts. A type is accessible
<a href="6.doc.html#33916">(§6.6)</a> outside the package that declares it only if the type is declared <code>public</code>.
<p><a name="26517"></a>
The naming structure for packages is hierarchical <a href="7.doc.html#26535">(§7.1)</a>. The members of a package are class and interface types <a href="7.doc.html#26783">(§7.6)</a>, which are declared in compilation units of the package, and subpackages, which may contain compilation units and subpackages of their own.<p>
<a name="40294"></a>
A package can be stored in a file system <a href="7.doc.html#37546">(§7.2.1)</a> or in a database <a href="7.doc.html#37739">(§7.2.2)</a>. Packages that are stored in a file system have certain constraints on the organization of their compilation units to allow a simple implementation to find classes easily. In either case, the set of packages available to a Java program is determined by the host system, but must always include at least the three standard packages <code>java.lang</code>, <code>java.util</code>, and <code>java.io</code> as specified in Chapters <a href="javalang.doc.html#">20</a>, <a href="javautil.doc.html#">21</a>, and <a href="javaio.doc14.html#29544">22</a>. In most host environments, the standard packages <code>java.applet</code>, <code>java.awt</code>, and <code>java.net</code>, which are not described in this specification, are also available to Java programs.<p>
<a name="26522"></a>
A package consists of a number of compilation units <a href="7.doc.html#40031">(§7.3)</a>. A compilation unit automatically has access to all types declared in its package and also automatically imports<i> </i>each of the types declared in the predefined package<i> </i><code>java.lang</code>.<p>
<a name="35454"></a>
A compilation unit has three parts, each of which is optional:<p>
<ul><a name="13571"></a>
<li>A <code>package</code> declaration <a href="7.doc.html#26619">(§7.4)</a>, giving the fully qualified name <a href="6.doc.html#25430">(§6.7)</a> of the package to which the compilation unit belongs
<a name="13599"></a>
<li><code>import</code> declarations <a href="7.doc.html#26656">(§7.5)</a> that allow types from other packages to be referred to using their simple names
<a name="13606"></a>
<li>Type declarations <a href="7.doc.html#26783">(§7.6)</a> of class and interface types
</ul><a name="26526"></a>
For small programs and casual development, a package can be unnamed <a href="7.doc.html#26639">(§7.4.2)</a> or have a simple name, but if Java code is to be widely distributed, unique package names should be chosen <a href="7.doc.html#40169">(§7.7)</a>. This can prevent the conflicts that would otherwise occur if two development groups happened to pick the same package name and these packages were later to be used in a single program.<p>
<a name="26535"></a>
<h2>7.1 Package Members</h2>
<a name="37172"></a>
A<i> package</i> can have members of either or both of the following kinds:
<p><ul><a name="29038"></a>
<li>Subpackages of the package
<a name="29031"></a>
<li>Types declared in the compilation units <a href="7.doc.html#40031">(§7.3)</a> of the package
</ul><a name="37558"></a>
For example, in the standard Java Application Programming Interface:
<p><ul><a name="37559"></a>
<li>The package <code>java</code> has subpackages <code>awt</code>, <code>applet</code>, <code>io</code>, <code>lang</code>, <code>net</code>, and <code>util</code>, but no compilation units.
<a name="37560"></a>
<li>The package <code>java.awt</code> has a subpackage named <code>image</code>, as well as a number of compilation units containing declarations of class and interface types.
</ul><a name="13127"></a>
If the fully qualified name <a href="6.doc.html#25430">(§6.7)</a> of a package is <i>P</i><i></i>, and <i>Q</i> is a subpackage of <i>P</i>,
then <i>P</i><code>.</code><i>Q</i> is the fully qualified name of the subpackage.
<p><a name="37562"></a>
The subpackages of package <code>java</code> named <code>lang</code>, <code>util</code>, and <code>io</code> (whose fully qualified package names are therefore <code>java.lang</code>, <code>java.util</code>, and <code>java.io</code>) are a standard part of every Java implementation and are specified in Chapters <a href="javalang.doc.html#">20</a>, <a href="javautil.doc.html#">21</a>, and <a href="javaio.doc9.html#28749">22</a>. Many Java implementations will include the entire set of <code>java</code> packages defined in the series of books <i>The Java Application Programming Interface</i>.<p>
<a name="37573"></a>
A package may not contain a type declaration and a subpackage of the same name, or a compile-time error results. Here are some examples:<p>
<ul><a name="37575"></a>
<li>Because the package <code>java.awt</code> has a subpackage <code>image</code>, it cannot (and does not) contain a declaration of a class or interface type named <code>image</code>.
<a name="37576"></a>
<li>If there is a package named <code>mouse</code> and a type <code>Button</code> in that package (which then might be referred to as <code>mouse.Button</code>), then there cannot be any package with the fully qualified name <code>mouse.Button</code> or <code>mouse.Button.Click</code>.
<a name="61007"></a>
<li>If <code>COM.Sun.java.jag</code> is the fully qualified name of a type, then there cannot be any package whose fully qualified name is either <code>COM.Sun.java.jag</code> or <code>COM.Sun.java.jag.scrabble</code>.
</ul><a name="61009"></a>
The hierarchical naming structure for packages is intended to be convenient for organizing related packages in a conventional manner, but has no significance in the Java language itself other than the prohibition against a package having a subpackage with the same simple name as a type declared in that package. There is no special access relationship in the Java language between a package named <code>oliver</code> and another package named <code>oliver.twist</code>, or between packages named <code>evelyn.wood</code> and <code>evelyn.Waugh</code>. For example, the code in a package named <code>oliver.twist</code> has no better access to the types declared within package <code>oliver</code> than code in any other package.<p>
<a name="37758"></a>
<h2>7.2 Host Support for Packages</h2>
<a name="37780"></a>
Each Java host determines how packages, compilation units, and subpackages are
created and stored; which top-level package names are in scope in a particular
compilation; and which packages are accessible.
<p><a name="37759"></a>
The packages may be stored in a local file system in simple implementations of Java. Other implementations may use a distributed file system or some form of database to store Java source and/or binary code.<p>
<a name="37546"></a>
<h3>7.2.1 Storing Packages in a File System</h3>
<a name="37463"></a>
As an extremely simple example, all the Java packages and source and binary
code on a system 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. The directory
might contain the following immediate subdirectories:
<p><pre><a name="37473"></a>
COM
<a name="13211"></a>gls
<a name="13212"></a>jag
<a name="13213"></a>java
<a name="13214"></a>wnj
</pre><a name="37477"></a>
where directory <code>java</code> would contain the standard Java Application Programming
Interface packages that are part of every standard Java system; the directories <code>jag</code>,
<code>gls</code>, and <code>wnj</code> might contain packages that the three authors of this specification
created for their personal use and to share with each other within this small group;
and the directory <code>COM</code> would contain packages procured from companies that used
the conventions described in <a href="7.doc.html#40169">§7.7</a> to generate unique names for their packages.
<p><a name="37480"></a>
Continuing the example, the directory <code>java</code> would probably contain at least the following subdirectories:<p>
<pre><a name="37481"></a>
applet
<a name="13215"></a>awt
<a name="13216"></a>io
<a name="13217"></a>lang
<a name="13218"></a>net
<a name="13219"></a>util
</pre><a name="37490"></a>
corresponding to the standard packages <code>java.applet</code>, <code>java.awt</code>, <code>java.io</code>,
<code>java.lang</code>, <code>java.net</code>, and <code>java.util</code> that are defined as part of the standard
Java Application Programming Interface.
<p><a name="37491"></a>
Still continuing the example, if we were to look inside the directory <code>util</code>, we might see the following files:<p>
<pre><a name="37492"></a>
BitSet.java Observable.java
<a name="37493"></a>BitSet.class Observable.class
<a name="37494"></a>Date.java Observer.java
<a name="37495"></a>Date.class Observer.class
<a name="37496"></a>Dictionary.java Properties.java
<a name="37497"></a>Dictionary.class Properties.class
<a name="37500"></a>EmptyStackException.java Random.java
<a name="37501"></a>EmptyStackException.class Random.class
<a name="37502"></a>Enumeration.java Stack.java
<a name="37503"></a>Enumeration.class Stack.class
<a name="37504"></a>Hashtable.java StringTokenizer.java
<a name="37505"></a>Hashtable.class StringTokenizer.class
<a name="37506"></a>NoSuchElementException.java Vector.java
<a name="37507"></a>NoSuchElementException.class Vector.class
</pre><a name="37466"></a>
where each of the <code>.java</code> files contains the source for a compilation unit <a href="7.doc.html#40031">(§7.3)</a>
that contains the definition of a class or interface whose binary compiled form is
contained in the corresponding <code>.class</code> file.
<p><a name="37599"></a>
Under this simple organization of packages, an implementation of Java would transform a package name into a pathname by concatenating the components of the package name, placing a file name separator (directory indicator) between adjacent components. For example, if this simple organization were used on a UNIX system, where the file name separator is <code>/</code>, the package name:<p>
<pre><a name="37600"></a>jag.scrabble.board
</pre><a name="37601"></a>
would be transformed into the directory name:
<p><pre><a name="37602"></a>jag/scrabble/board
</pre><a name="37603"></a>
and:
<p><pre><a name="37604"></a>COM.Sun.sunsoft.DOE
</pre><a name="37605"></a>
would be transformed to the directory name:
<p><pre><a name="37606"></a><code>COM/Sun/sunsoft/DOE
</code></pre><a name="37608"></a>
In fact, the standard JavaSoft Java Developer's Kit on UNIX differs from the very simple discipline described here only in that it provides a <code>CLASSPATH</code> environment variable that specifies a set of directories, each of which is treated like the single directory described here. These directories are searched in order for definitions of named packages and types.<p>
<a name="37709"></a>
A package name component or class name might contain a character that cannot correctly appear in a host file system's ordinary directory name, such as a Unicode character on a system that allows only ASCII characters in file names. As a convention, the character can be escaped by using, say, the <code>@</code> character followed by four hexadecimal digits giving the numeric value of the character, as in the <code>\u</code><i>xxxx</i> escape <a href="3.doc.html#100850">(§3.3)</a>, so that the package name:<p>
<pre><a name="37613"></a>children.activities.crafts.papierM\u00e2ch\u00e9
</pre><a name="37614"></a>
which can also be written using full Unicode as:
<p><pre><a name="37615"></a>children.activities.crafts.papierMâché
</pre><a name="37616"></a>
might be mapped to the directory name:
<p><pre><a name="37617"></a>children/activities/crafts/papierM@00e2ch@00e9
</pre><a name="37618"></a>
If the <code>@</code> character is not a valid character in a file name for some given host file
system, then some other character that is not valid in a Java identifier could be
used instead.
<p><a name="37739"></a>
<h3>7.2.2 Storing Packages in a Database</h3>
<a name="37740"></a>
A host system may store packages and their compilation units and subpackages in
a database.
<p><a name="35013"></a>
Java allows such a database to relax the restrictions <a href="7.doc.html#26783">(§7.6)</a> on compilation units in file-based implementations. For example, a system that uses a database to store packages need not enforce a maximum of one <code>public</code> class or interface per compilation unit. Systems that use a database must, however, provide an option to convert a Java program to a form that obeys the restrictions, for purposes of export to file-based implementations.<p>
<a name="40031"></a>
<h2>7.3 Compilation Units</h2>
<a name="26594"></a>
<i>CompilationUnit </i>is the goal symbol <a href="2.doc.html#40415">(§2.1)</a> for the syntactic grammar <a href="2.doc.html#140845">(§2.3)</a> of
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -