7.doc.html

java语言规范

Java programs. It is defined by the following productions:
<p><ul><pre>
<i>CompilationUnit:<br>
	PackageDeclaration</i><sub><i>opt</i></sub><code> </code><i>ImportDeclarations</i><sub><i>opt</i></sub><code> </code><i>TypeDeclarations</i><sub><i>opt
</i></sub>
<i>ImportDeclarations:<br>
</i>	<i>ImportDeclaration<br>
</i>	<i>ImportDeclarations</i><code> </code><i>ImportDeclaration
</i>
<i>TypeDeclarations:<br>
</i>	<i>TypeDeclaration<br>
</i>	<i>TypeDeclarations</i><code> </code><i>TypeDeclaration
</i></pre></ul><a name="24124"></a>
Types declared in different compilation units can depend on each other, circularly. 
A Java compiler must arrange to compile all such types at the same time.
<p><a name="35022"></a>
A <i>compilation unit</i> consists of three parts, each of which is optional:<p>
<ul><a name="35029"></a>
<li>A <code>package</code> declaration <a href="7.doc.html#26619">(&#167;7.4)</a>, giving the fully qualified name <a href="6.doc.html#25430">(&#167;6.7)</a> of the package to which the compilation unit belongs
<a name="35033"></a>
<li><code>import</code> declarations <a href="7.doc.html#26656">(&#167;7.5)</a> that allow types from other packages to be referred to using their simple names
<a name="35037"></a>
<li>Type declarations <a href="7.doc.html#26783">(&#167;7.6)</a> of class and interface types
</ul><a name="26614"></a>
Every compilation unit automatically and implicitly imports every <code>public</code> type name declared in the predefined package <code>java.lang</code>, so that the names of all those types are available as simple names, as described in <a href="7.doc.html#26741">&#167;7.5.3</a>.<p>
<a name="26619"></a>
<h2>7.4    Package Declarations</h2>
<a name="35052"></a>
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.
<p><a name="26621"></a>
<h3>7.4.1    Named Packages</h3>
<a name="26626"></a>
A <i>package declaration</i> in a compilation unit specifies the name <a href="6.doc.html#31692">(&#167;6.2)</a> of the package
to which the compilation unit belongs.
<p><ul><pre>
<i>PackageDeclaration:<br>
	</i><code>package </code><i>PackageName</i><code> ;
</code></pre></ul><a name="26629"></a>
The package name mentioned in a package declaration must be the fully qualified 
name <a href="6.doc.html#25430">(&#167;6.7)</a> of the package.
<p><a name="26630"></a>
If a type named <i>T</i><em></em> is declared in a compilation unit of a package whose fully qualified name is <i>P</i>, then the fully qualified name of the type is <i>P</i><code>.</code><i>T</i>; thus in the example:<p>
<pre><a name="26635"></a>package wnj.points;
<a name="26636"></a>class Point { int x, y; }
</pre><a name="26637"></a>
the fully qualified name of class <code>Point</code> is <code>wnj.points.Point</code>. 
<p><a name="26639"></a>
<h3>7.4.2    Unnamed Packages</h3>
<a name="26640"></a>
A compilation unit that has no package declaration is part of an unnamed package. 
As an example, the compilation unit:
<p><pre><a name="35107"></a>
class FirstCall {
<a name="35108"></a>	public static void main(String[] args) {
<a name="35110"></a>		System.out.println("Mr. Watson, come here. "
<a name="35111"></a>									+ "I want you.");
<a name="35112"></a>	}
<a name="35113"></a>}
</pre><a name="35114"></a>
defines a very simple compilation unit as part of an unnamed package.
<p><a name="26641"></a>
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.<p>
<a name="35086"></a>
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.<p>
<a name="35134"></a>
Unnamed packages are provided by Java principally for convenience when developing small or temporary applications or when just beginning development.<p>
<a name="37842"></a>
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 <code>public</code>, to keep them from accidentally being imported by a named package.<p>
<a name="35133"></a>
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.<p>
<a name="13180"></a>
<h3>7.4.3    Scope and Hiding of a Package Name</h3>
<a name="13187"></a>
Which top-level package names are in scope (<a href="6.doc.html#33623">&#167;6.3</a>, <a href="6.doc.html#20569">&#167;6.5</a>) is determined by conventions
of the host system.
<p><a name="35593"></a>
Package names never hide other names.<p>
<a name="13194"></a>
<h3>7.4.4    Access to Members of a Package</h3>
<a name="13195"></a>
Whether access to members of a package is allowed is determined by the host system.
The package <code>java</code> should always be accessible, and its standard subpackages 
<code>lang</code>, <code>io</code>, and <code>util</code> should always be accessible.
<p><a name="13244"></a>
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.<p>
<a name="26656"></a>
<h2>7.5    Import Declarations</h2>
<a name="26658"></a>
An <i>import declaration</i> allows a type declared in another package to be referred to 
by a simple name <a href="6.doc.html#31692">(&#167;6.2)</a> that consists of a single identifier. Without the use of an 
appropriate <code>import</code> declaration, the only way to refer to a type declared in another 
package is to use its fully qualified name <a href="6.doc.html#25430">(&#167;6.7)</a>.
<p><ul><pre>
<i>ImportDeclaration:<br>
</i>	<i>SingleTypeImportDeclaration<br>
</i>	<i>TypeImportOnDemandDeclaration
</i></pre></ul><a name="37962"></a>
A single-type-import declaration <a href="7.doc.html#26699">(&#167;7.5.1)</a> imports a single type, by mentioning its fully qualified name. A type-import-on-demand declaration <a href="7.doc.html#26725">(&#167;7.5.2)</a> imports all the <code>public</code> types of a named package as needed.<p>
<a name="37929"></a>
An <code>import</code> declaration makes types available by their simple names only within the compilation unit that actually contains the <code>import</code> declaration. The scope of the name(s) it introduces specifically does not include the <code>package</code> statement, other <code>import</code> statements in the current compilation unit, or other compilation units in the same package. Please see <a href="7.doc.html#24151">&#167;7.5.4</a> for an illustrative example.<p>
<a name="26699"></a>
<h3>7.5.1    Single-Type-Import Declaration</h3>
<a name="13275"></a>
A <i>single-type-import declaration </i>imports a single type by giving its fully qualified 
name, making it available under a simple name in the class and interface declarations
of its compilation unit.
<p><ul><pre>
<i>SingleTypeImportDeclaration:<br>
</i><code>	import </code><i>TypeName</i><code> ;
</code></pre></ul><a name="29086"></a>
The <i>TypeName</i> must be the fully qualified name of a class or interface type; a 
compile-time error occurs if the named type does not exist. If the named type is 
not in the current package, then it must be accessible <a href="6.doc.html#33916">(&#167;6.6)</a>-in an accessible 
package and declared <code>public</code> (<a href="8.doc.html#21613">&#167;8.1.2</a>, <a href="9.doc.html#235947">&#167;9.1.2</a>)-or a compile-time error occurs.
<p><a name="37971"></a>
The example:<p>
<pre><a name="26702"></a>import java.util.Vector;
</pre><a name="45771"></a>
causes the simple name <code>Vector</code> to be available within the class and interface declarations
in a compilation unit. Thus, the simple name <code>Vector</code> refers to the type 
<code>Vector</code> in the package <code>java.util</code> in all places where it is not hidden <a href="6.doc.html#33623">(&#167;6.3)</a> by a 
declaration of a field, parameter, or local variable with the same name.
<p><a name="29151"></a>
If two single-type-import declarations in the same compilation unit attempt to import types with the same simple name, then a compile-time error occurs, unless the two types are the same type, in which case the duplicate declaration is ignored. If another type with the same name is otherwise declared in the current compilation unit except by a type-import-on-demand declaration <a href="7.doc.html#26725">(&#167;7.5.2)</a>, then a compile-time error occurs. <p>
<a name="29134"></a>
So the sample program:<p>
<pre><br><a name="29135"></a>import java.util.Vector;
<br><a name="29136"></a>class Vector { Object[] vec; }
</pre><a name="29137"></a>
causes a compile-time error because of the duplicate declaration of <code>Vector</code>, as 
does:
<p><pre><br><a name="29138"></a>import java.util.Vector;
<br><a name="29139"></a>import myVector.Vector;
</pre><a name="29140"></a>
where <code>myVector</code> is a package containing the compilation unit:
<p><pre><br><a name="29141"></a>package myVector;
<br><a name="29142"></a>public class Vector { Object[] vec; }
</pre><a name="29113"></a>
The compiler keeps track of types by their fully qualified names <a href="6.doc.html#25430">(&#167;6.7)</a>. Simple names and fully qualified names may be used interchangeably whenever they are both available.<p>
<a name="60471"></a>
Note that an import statement cannot import a subpackage, only a type. For example, it does not work to try to import <code>java.util</code> and then use the name <code>util.Random</code> to refer to the type <code>java.util.Random</code>:<p>
<pre><br><a name="60474"></a>import java.util;										// incorrect: compile-time error
<br><a name="60475"></a>class Test { util.Random generator; }
</pre><a name="26725"></a>
<h3>7.5.2    Type-Import-on-Demand Declaration</h3>
<a name="26727"></a>
A <i>type-import-on-demand declaration</i> allows all <code>public</code> types declared in the 
package named by a fully qualified name to be imported as needed.
<p><ul><pre>
<i>TypeImportOnDemandDeclaration:<br>
	</i><code>import </code><i>PackageName</i><code> . * ;
</code></pre></ul><a name="29163"></a>
It is a compile-time error for a type-import-on-demand declaration to name a 
package that is not accessible <a href="6.doc.html#33916">(&#167;6.6)</a>, as determined by the host system <a href="7.doc.html#37758">(&#167;7.2)</a>. 
Two or more type-import-on-demand declarations in the same compilation unit 
may name the same package; the effect is as if there were exactly one such declaration.
It is not a compile-time error to name the current package or <code>java.lang</code> in 
a type-import-on-demand declaration, even though they are already imported; the 
duplicate type-import-on-demand declaration is ignored.
<p><a name="35214"></a>
The example:<p>
<pre><a name="35215"></a>import java.util.*;
</pre><a name="35216"></a>
causes the simple names of all <code>public</code> types declared in the package <code>java.util</code> 
to be available within the class and interface declarations of the compilation unit.