7.doc.html

java语言规范

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 single-type-import declaration
of a type whose simple name is <code>Vector</code>; by a type named <code>Vector</code> and 
declared in the package to which the compilation unit belongs; or by a declaration 
of a field, parameter, or local variable named <code>Vector</code>. (It would be unusual for any 
of these conditions to occur.)
<p><a name="26741"></a>
<h3>7.5.3    Automatic Imports</h3>
<a name="26743"></a>
Each compilation unit automatically imports each of the<i> </i><code>public</code><i> </i>type names 
declared in the predefined package<i> </i><code>java.lang</code>, as if the declaration:
<p><pre><a name="26744"></a>import java.lang.*;
</pre><a name="26745"></a>
appeared at the beginning of each compilation unit, immediately following any 
<code>package</code> statement.
<p><a name="26749"></a>
The full specification of <code>java.lang</code> is given in Chapter <a href="javalang.doc.html#">20</a>. The following <code>public</code> types are defined in <code>java.lang</code>:<p>
<pre><a name="26750"></a>
AbstractMethodError										LinkageError
<a name="26751"></a>ArithmeticException										Long
<a name="26753"></a>ArrayStoreException										Math
<a name="35299"></a>Boolean										NegativeArraySizeException
<a name="35300"></a>Character										NoClassDefFoundError
<a name="35301"></a>Class										NoSuchFieldError
<a name="35302"></a>ClassCastException										NoSuchMethodError
<a name="26758"></a>ClassCircularityError										NullPointerException
<a name="61567"></a>ClassFormatError										Number
<a name="61568"></a>ClassLoader										NumberFormatException
<a name="61569"></a>ClassNotFoundException										Object
<a name="26762"></a>CloneNotSupportedException										OutOfMemoryError
<a name="26763"></a>Cloneable										Process
<a name="26764"></a>Compiler										Runnable
<a name="26765"></a>Double										Runtime
<a name="26766"></a>Error										RuntimeException
<a name="26767"></a>Exception										SecurityException
<a name="34240"></a>ExceptionInInitializerError										SecurityManager
<a name="35238"></a>Float										StackOverflowError
<a name="35239"></a>IllegalAccessError										String
<a name="35240"></a>IllegalAccessException										StringBuffer
<a name="26771"></a>IllegalArgumentException										System
<a name="61639"></a>IllegalMonitorStateException										Thread
<a name="61640"></a>IllegalThreadStateException										ThreadDeath
<a name="61641"></a>IncompatibleClassChangeError										ThreadGroup
<a name="61634"></a>IndexOutOfBoundsException										Throwable
<a name="26776"></a>InstantiationError										UnknownError
<a name="26777"></a>InstantiationException										UnsatisfiedLinkError
<a name="26778"></a>Integer										VerifyError
<a name="26779"></a>InternalError										VirtualMachineError
<a name="26780"></a>InterruptedException
</pre><a name="24151"></a>
<h3>7.5.4    A Strange Example</h3>
<a name="24152"></a>
Package names and type names are usually different under the naming conventions
described in <a href="6.doc.html#11186">&#167;6.8</a>. Nevertheless, in a contrived example where there is an 
unconventionally-named package <code>Vector</code>, which declares a <code>public</code> class named 
<code>Mosquito</code>:
<p><pre><br><a name="24156"></a>package Vector;
<br><a name="24157"></a>public class Mosquito { int capacity; }
</pre><a name="24158"></a>
and then the compilation unit:
<p><pre><br><a name="24159"></a>package strange.example;
<br><br><a name="35349"></a>import java.util.Vector;
<br><br><a name="24160"></a>import Vector.Mosquito;
<br></pre><pre><a name="24161"></a>
class Test {
<a name="24162"></a>	public static void main(String[] args) {
<a name="24163"></a>		System.out.println(new Vector().getClass());
<a name="24164"></a>		System.out.println(new Mosquito().getClass());
<a name="24165"></a>	}
<a name="24166"></a>}
</pre><a name="24170"></a>
the single-type-import declaration <a href="7.doc.html#26699">(&#167;7.5.1)</a> importing class <code>Vector</code> from package 
<code>java.util</code> does not prevent the package name <code>Vector</code> from appearing and being 
correctly recognized in subsequent <code>import</code> declarations. The example compiles 
and produces the output:
<p><pre><a name="24171"></a>
class java.util.Vector
<a name="24172"></a>class Vector.Mosquito
</pre><a name="26783"></a>
<h2>7.6    Type Declarations</h2>
<a name="26790"></a>
A type declaration declares a class type <a href="8.doc.html#3857">(&#167;8)</a> or an interface type <a href="9.doc.html#238678">(&#167;9)</a>:
<p><ul><pre>
<i>TypeDeclaration:<br>
</i>	<i>ClassDeclaration<br>
</i>	<i>InterfaceDeclaration<br>
</i>	<code>;
</code></pre></ul><a name="61526"></a>
A Java compiler must ignore extra "<code>;</code>" tokens appearing at the level of type declarations. Stray semicolons are permitted in Java solely as a concession to C++ programmers who are used to writing:<p>
<pre><a name="61527"></a>class date { int month, day, year; };
</pre><a name="61528"></a>
(In C++, but not in Java, one can provide a comma-separated list of identifiers in 
order to declare variables between the "<code>}</code>" and the "<code>;</code>".) Extra semicolons should 
not be used in new Java code. Software that reformats Java code can delete them.
<p><a name="37662"></a>
By default, the types declared in a package are accessible only within the compilation units of that package, but a type may be declared to be <code>public</code> to grant access to the type from code in other packages (<a href="6.doc.html#33916">&#167;6.6</a>, <a href="8.doc.html#21613">&#167;8.1.2</a>, <a href="9.doc.html#235947">&#167;9.1.2</a>).<p>
<a name="26802"></a>
A Java implementation must keep track of types within packages by their fully qualified names <a href="6.doc.html#25430">(&#167;6.7)</a>. Multiple ways of naming a type must be expanded to fully qualified names to make sure that such names are understood as referring to the same type. For example, if a compilation unit contains the single-type-import declaration <a href="7.doc.html#26699">(&#167;7.5.1)</a>:<p>
<pre><a name="26806"></a>import java.util.Vector;
</pre><a name="26807"></a>
then within that compilation unit the simple name <code>Vector</code> and the fully qualified 
name <code>java.util.Vector</code> refer to the same type.
<p><a name="40154"></a>
When Java packages are stored in a file system <a href="7.doc.html#37546">(&#167;7.2.1)</a>, the host system may choose to enforce the restriction that it is a compile-time error if a type is not found in a file under a name composed of the type name plus an extension (such as <code>.java</code> or <code>.jav</code>) if either of the following is true:<p>
<ul><a name="40155"></a>
<li>The type is referred to by code in other compilation units of the package in which the type is declared.
<a name="40159"></a>
<li>The type is declared <code>public</code> (and therefore is potentially accessible from code in other packages).
</ul><a name="40156"></a>
This restriction implies that there must be at most one such type per compilation 
unit. This restriction makes it easy for a Java compiler and Java Virtual Machine 
to find a named class within a package; for example, the source code for a <code>public</code> 
type <code>wet.sprocket.Toad</code> would be found in a file <code>Toad.java</code> in the directory 
<code>wet/sprocket</code>, and the corresponding object code would be found in the file 
<code>Toad.class</code> in the same directory.
<p><a name="20150"></a>
When Java packages are stored in a database <a href="7.doc.html#37739">(&#167;7.2.2)</a>, the host system need not enforce such restrictions.<p>
<a name="40175"></a>
In practice, many Java programmers choose to put each class or interface type in its own compilation unit, whether or not it is <code>public</code> or is referred to by code in other compilation units.<p>
<a name="40169"></a>
<h2>7.7    Unique Package Names</h2>
<a name="37792"></a>
Developers should take steps to avoid the possibility of two published packages 
having the same name by choosing <i>unique package names</i> for packages that are 
widely distributed. This allows packages to be easily and automatically installed 
and catalogued. This section specifies a standard convention, not enforced by a 
Java compiler, for generating such unique package names. Java systems are 
encouraged to provide automatic support for converting a set of packages from 
local and casual package names to the unique name format described here.
<p><a name="37825"></a>
If unique package names are not used, then package name conflicts may arise far from the point of creation of either of the conflicting packages. This may create &#32;a situation that is difficult or impossible for the user or programmer to resolve. The class <code>ClassLoader</code> <a href="javalang.doc13.html#14462">(&#167;20.14)</a> of the standard Java Virtual Machine environment can be used to isolate packages with the same name from each other in those cases where the packages will have constrained interactions, but not in a way that is transparent to a na&iuml;ve Java program.<p>
<a name="26818"></a>
You form a unique package name by first having (or belonging to an organization that has) an Internet domain name, such as <code>Sun.COM</code>. You then reverse this name, component by component, to obtain, in this example, <code>COM.Sun</code>, and use this as a prefix for your package names, using a convention developed within your organization to further administer package names.<p>
<a name="26819"></a>
Such a convention might specify that certain directory name components be division, department, project, machine, or login names. Some possible examples:<p>
<pre><a name="26820"></a>
COM.Sun.sunsoft.DOE
<a name="26821"></a>COM.Sun.java.jag.scrabble
<a name="26822"></a>COM.Apple.quicktime.v2
<a name="26823"></a>EDU.cmu.cs.bovik.cheese
<a name="26824"></a>GOV.whitehouse.socks.mousefinder
</pre><a name="26825"></a>
The first component of a unique package name is always written in all-uppercase 
ASCII letters and should be one of the top-level domain names, currently <code>COM</code>, 
<code>EDU</code>, <code>GOV</code>, <code>MIL</code>, <code>NET</code>, <code>ORG</code>, or one of the English two-letter codes identifying countries
as specified in ISO Standard 3166, 1981. For more information, refer to the 
documents stored at <code>ftp://rs.internic.net/rfc</code>, for example, <code>rfc920.txt</code> 
and <code>rfc1032.txt</code>.
<p><a name="26826"></a>
The name of a package is not meant to imply anything about where the package is stored within the Internet; for example, a package named <code>EDU.cmu.cs.bovik.cheese</code> is not necessarily obtainable from Internet address <code>cmu.EDU</code> or from <code>cs.cmu.EDU</code> or from <code>bovik.cs.cmu.EDU</code>. The Java convention for generating unique package names is merely a way to piggyback a package naming convention on top of an existing, widely known unique name registry instead of having to create a separate registry for Java package names.<p>
<a name="60426"></a>
If you need to get a new Internet domain name, you can get an application form from <code>ftp://ftp.internic.net</code> and submit the complete forms by E-mail to <code>[e-mail]</code>. To find out what the currently registered domain names are, you can <code>telnet</code> to <code>rs.internic.net</code> and use the <code>whois</code> facility.<p>


<hr>
<!-- This inserts footnotes--><p>
<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>
<p>
<font size=-1>Java Language Specification (HTML generated by Suzette Pelouch on February 24, 1998)<br>
<i><a href="jcopyright.doc.html">Copyright &#169 1996 Sun Microsystems, Inc.</a>
All rights reserved</i>
<br>
Please send any comments or corrections to <a href="mailto:[e-mail]">[e-mail]</a>
</font>
</body></html>