9.doc.html

java语言规范

<a name="41011"></a>	int k = k+1;
<a name="41012"></a>}
</pre><a name="41013"></a>
causes two compile-time errors, because <code>j</code> is referred to in the initialization of <code>f</code> 
before <code>j</code> is declared and because the initialization of <code>k</code> refers to <code>k</code> itself.
<p><a name="236702"></a>
(One subtlety here is that, at run time, <code>fields</code> that are initialized with compile-time constant values are initialized first. This applies also to <code>static</code> <code>final</code> fields in classes <a href="8.doc.html#38010">(&#167;8.3.2.1)</a>. This means, in particular, that these fields will never be observed to have their default initial values <a href="4.doc.html#10931">(&#167;4.5.4)</a>, even by devious programs. See <a href="12.doc.html#44630">&#167;12.4.2</a> and <a href="13.doc.html#45139">&#167;13.4.8</a> for more discussion.)<p>
<a name="41024"></a>
If the keyword <code>this</code> <a href="15.doc.html#31980">(&#167;15.7.2)</a> or the keyword <code>super</code> (<a href="15.doc.html#20860">15.10.2</a>, <a href="15.doc.html#20448">15.11</a>) occurs in an initialization expression for a field of an interface, then a compile-time error occurs.<p>
<a name="40595"></a>
<h3>9.3.2    Examples of Field Declarations</h3>
<a name="40743"></a>
The following example illustrates some (possibly subtle) points about field declarations.

<p><a name="40596"></a>
<h4>9.3.2.1    Ambiguous Inherited Fields</h4>
<a name="40648"></a>
If two fields with the same name are inherited by an interface because, for example,
two of its direct superinterfaces declare fields with that name, then a single 
<i>ambiguous member</i> results. Any use of this ambiguous member will result in a 
compile-time error. Thus in the example:
<p><pre><a name="40649"></a>
interface BaseColors {
<a name="40650"></a>	int RED = 1, GREEN = 2, BLUE = 4;
<a name="40651"></a>}
<br><a name="40652"></a>
interface RainbowColors extends BaseColors {
<a name="40653"></a>	int YELLOW = 3, ORANGE = 5, INDIGO = 6, VIOLET = 7;
<a name="40654"></a>}
<br><a name="40655"></a>
interface PrintColors extends BaseColors {
<a name="40656"></a>	int YELLOW = 8, CYAN = 16, MAGENTA = 32;
<a name="40657"></a>}
<br><a name="40658"></a>
interface LotsOfColors extends RainbowColors, PrintColors {
<a name="40659"></a>	int FUCHSIA = 17, VERMILION = 43, CHARTREUSE = RED+90;
<a name="40660"></a>}
</pre><a name="40661"></a>
the interface <code>LotsOfColors</code> inherits two fields named <code>YELLOW</code>. This is all right as 
long as the interface does not contain any reference by simple name to the field 
<code>YELLOW</code>. (Such a reference could occur within a variable initializer for a field.)
<p><a name="40696"></a>
Even if interface <code>PrintColors</code> were to give the value <code>3</code> to <code>YELLOW</code> rather than the value <code>8</code>, a reference to field <code>YELLOW</code> within interface <code>LotsOfColors</code> would still be considered ambiguous.<p>
<a name="40599"></a>
<h4>9.3.2.2    Multiply Inherited Fields</h4>
<a name="236005"></a>
If a single field is inherited multiple times from the same interface because, for 
example, both this interface and one of this interface's direct superinterfaces 
extend the interface that declares the field, then only a single member results. This 
situation does not in itself cause a compile-time error. 
<p><a name="236006"></a>
In the example in the previous section, the fields <code>RED</code>, <code>GREEN</code>, and <code>BLUE</code> are inherited by interface <code>LotsOfColors</code> in more than one way, through interface <code>RainbowColors</code> and also through interface <code>PrintColors</code>, but the reference to field <code>RED</code> in interface <code>LotsOfColors</code> is not considered ambiguous because only one actual declaration of the field <code>RED</code> is involved.<p>
<a name="78651"></a>
<h2>9.4    Abstract Method Declarations</h2>
<ul><pre>
<i>AbstractMethodDeclaration:<br>
</i>	<i>AbstractMethodModifiers</i><sub><i>opt</i></sub><code> </code><i>ResultType</i><code> </code><i>MethodDeclarator</i><code> </code><i>Throws</i><sub><i>opt</i></sub><code> ;
</code>
<i>AbstractMethodModifiers:<br>
</i>	<i>AbstractMethodModifier<br>
</i>	<i>AbstractMethodModifiers</i><code> </code><i>AbstractMethodModifier
</i>
<i>AbstractMethodModifier:</i> <i>one</i> <i>of<br>
</i>	<code>public&#32;abstract
</code></pre></ul><a name="36046"></a>
The access modifier <code>public</code> is discussed in <a href="6.doc.html#33916">&#167;6.6</a>. A compile-time error occurs if 
the same modifier appears more than once in an abstract method declaration.
<p><a name="78653"></a>
Every method declaration in the body of an interface is implicitly <code>abstract</code>, so its body is always represented by a semicolon, not a block. For compatibility with older versions of Java, it is permitted but discouraged, as a matter of style, to redundantly specify the <code>abstract</code> modifier for methods declared in interfaces.<p>
<a name="78654"></a>
Every method declaration in the body of an interface is implicitly <code>public</code>. It is permitted, but strongly discouraged as a matter of style, to redundantly specify the <code>public</code> modifier for interface methods.<p>
<a name="38687"></a>
Note that a method declared in an interface must not be declared <code>static</code>, or a compile-time error occurs, because in Java <code>static</code> methods cannot be <code>abstract</code>.<p>
<a name="38689"></a>
Note that a method declared in an interface must not be declared <code>native</code> or <code>synchronized</code>, or a compile-time error occurs, because those keywords describe implementation properties rather than interface properties. However, a method declared in an interface may be implemented by a method that is declared <code>native</code> or <code>synchronized</code> in a class that implements the interface.<p>
<a name="38671"></a>
Note that a method declared in an interface must not be declared <code>final</code> or a compile-time error occurs. However, a method declared in an interface may be implemented by a method that is declared <code>final</code> in a class that implements the interface.<p>
<a name="40247"></a>
<h3>9.4.1    Inheritance and Overriding</h3>
<a name="40229"></a>
If the interface declares a method, then the declaration of that method is said to 
<i>override</i> any and all methods with the same signature in the superinterfaces of the 
interface that would otherwise be accessible to code in this interface.
<p><a name="40233"></a>
If a method declaration in an interface overrides the declaration of a method in another interface, a compile-time error occurs if the methods have different return types or if one has a return type and the other is <code>void</code>. Moreover, a method declaration must not have a <code>throws</code> clause that conflicts <a href="8.doc.html#78323">(&#167;8.4.4)</a> with that of any method that it overrides; otherwise, a compile-time error occurs.<p>
<a name="236025"></a>
Methods are overridden on a signature-by-signature basis. If, for example, an interface declares two <code>public</code> methods with the same name, and a subinterface overrides one of them, the subinterface still inherits the other method.<p>
<a name="40237"></a>
An interface inherits from its direct superinterfaces all methods of the superinterfaces that are not overridden by a declaration in the interface.<p>
<a name="40238"></a>
It is possible for an interface to inherit more than one method with the same signature <a href="8.doc.html#38649">(&#167;8.4.2)</a>. Such a situation does not in itself cause a compile-time error. The interface is considered to inherit all the methods. However, a compile-time error occurs if, for any two such inherited methods, either they have different return types or one has a return type and the other is <code>void</code>. (The <code>throws</code> clauses do not cause errors in this case.)<p>
<a name="40242"></a>
There might be several paths by which the same method declaration is inherited from an interface. This fact causes no difficulty and never of itself results in a compile-time error.<p>
<a name="236017"></a>
<h3>9.4.2    Overloading</h3>
<a name="40243"></a>
If two methods of an interface (whether both declared in the same interface, or 
both inherited by a interface, or one declared and one inherited) have the same 
name but different signatures, then the method name is said to be <i>overloaded</i>. This 
fact causes no difficulty and never of itself results in a compile-time error. There is 
no required relationship between the return types or between the <code>throws</code> clauses 
of two methods with the same name but different signatures.
<p><a name="40248"></a>
<h3>9.4.3    Examples of Abstract Method Declarations</h3>
<a name="40738"></a>
The following examples illustrate some (possibly subtle) points about abstract 
method declarations.
<p><a name="40734"></a>
<h4>9.4.3.1    Example: Overriding</h4>
<a name="40251"></a>
Methods declared in interfaces are <code>abstract</code> and thus contain no implementation. 
About all that can be accomplished by an overriding method declaration, other 
than to affirm a method signature, is to restrict the exceptions that might be thrown 
by an implementation of the method. Here is a variation of the example shown in 
<a href="8.doc.html#34484">&#167;8.4.3.1</a>:
<p><pre><a name="40258"></a>
class BufferEmpty extends Exception {
<a name="40259"></a>	BufferEmpty() { super(); }
<a name="40260"></a>	BufferEmpty(String s) { super(s); }
<a name="40261"></a>}
<br><a name="40262"></a>
class BufferError extends Exception {
<a name="40263"></a>	BufferError() { super(); }
<a name="40264"></a>	BufferError(String s) { super(s); }
<a name="40265"></a>}
<br><a name="40266"></a>
public interface Buffer {
<a name="40267"></a>	char get() throws BufferEmpty, BufferError;
<a name="40268"></a>}
<br><a name="40269"></a>
public interface InfiniteBuffer extends Buffer {
<a name="40270"></a>	 char get() throws BufferError;												// override
<a name="40271"></a>}
</pre><a name="40735"></a>
<h4>9.4.3.2    Example: Overloading</h4>
<a name="40788"></a>
In the example code:
<p><pre><a name="40767"></a>
interface PointInterface {
<a name="40768"></a>	void move(int dx, int dy);
<a name="40770"></a>}
<br><a name="40772"></a>
interface RealPointInterface extends PointInterface {
<a name="40781"></a>	void move(float dx, float dy);
<a name="40783"></a>	void move(double dx, double dy);
<a name="40775"></a>}
</pre><a name="236063"></a>
the method name <code>move</code> is overloaded in interface <code>RealPointInterface</code> with 
three different signatures, two of them declared and one inherited. Any class that 
implements interface <code>RealPointInterface</code> must provide implementations of all 
three method signatures.
<p><a name="244753"></a>
<p>


<hr>
<!-- This inserts footnotes--><p>
<a href="index.html">Contents</a> | <a href="8.doc.html">Prev</a> | <a href="10.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>