<html>
<head>
<title> Interfaces</title>
</head>
<body BGCOLOR=#eeeeff text=#000000 LINK=#0000ff VLINK=#000077 ALINK=#ff0000>
<table border="0" width="100%">
<tr>
<td><a href="jTOC.doc.html">Contents</a> | <a href="classes.doc.html">Prev</a> | <a href="arrays.doc.html">Next</a> | <a href="jIX.fm.html">Index</a></td>
<td align=right><i>Java Language Specification</i><br>
<font size="-1">Second Edition</font></td></tr></table>
<hr><br>
<a name="238678"></a>
<p><strong>
CHAPTER
9 </strong></p>
<a name="238680"></a>
<h1>Interfaces</h1>
<hr><p>
<a name="236346"></a>
An interface declaration introduces a new reference type whose members are classes, interfaces, constants and abstract methods. This type has no implementation, but otherwise unrelated classes can implement it by providing implementations for its abstract methods.<p>
<a name="245713"></a>
A nested interface is any interface whose declaration occurs within the body of another class or interface. A top-level interface is an interface that is not a nested interface.<p>
<a name="245720"></a>
This chapter discusses the common semantics of all interfaces-top-level <a href="packages.doc.html#26783">(§7.6)</a> and nested (<a href="classes.doc.html#246026">§8.5</a>, <a href="interfaces.doc.html#252566">§9.5</a>). Details that are specific to particular kinds of interfaces are discussed in the sections dedicated to these constructs.<p>
<a name="247545"></a>
Programs can use interfaces to make it unnecessary for related classes to share a common abstract superclass or to add methods to <code>Object</code>.
<a name="247549"></a>
An interface may be declared to be a <em>direct extension </em>of one or more other interfaces, meaning that it implicitly specifies all the member types, abstract methods and constants of the interfaces it extends, except for any member types and constants that it may hide.<p>
<a name="30809"></a>
A class may be declared to <em>directly implement</em> one or more interfaces, meaning that any instance of the class implements all the abstract methods specified by the interface or interfaces. A class necessarily implements all the interfaces that its direct superclasses and direct superinterfaces do. This (multiple) interface inheritance allows objects to support (multiple) common behaviors without sharing any implementation.<p>
<a name="35467"></a>
A variable whose declared type is an interface type may have as its value a reference to any instance of a class which implements the specified interface. It is not sufficient that the class happen to implement all the abstract methods of the interface; the class or one of its superclasses must actually be declared to implement the interface, or else the class is not considered to implement the interface.<p>
<a name="35470"></a>
<h2>9.1 Interface Declarations</h2>
<a name="27727"></a>
An <em>interface declaration</em> specifies a new named reference type:<p>
<ul><pre>
<em>InterfaceDeclaration:
InterfaceModifiers<sub><i>opt</i></sub></em> interface <em>Identifier
ExtendsInterfaces<sub><i>opt</i></sub> InterfaceBody</em>
</pre></ul><a name="252341"></a>
The <em>Identifier</em> in an interface declaration specifies the name of the interface. A compile-time error occurs if an interface has the same simple name as any of its enclosing classes or interfaces. <p>
<a name="235947"></a>
<h3>9.1.1 Interface Modifiers</h3>
<a name="17033"></a>
An interface declaration may include <em>interface modifiers</em>:<p>
<ul><pre>
<em>InterfaceModifiers:
InterfaceModifier
InterfaceModifiers InterfaceModifier
InterfaceModifier: one of
</em> public protected private
abstract static strictfp
</pre></ul><a name="78582"></a>
The access modifier public is discussed in <a href="names.doc.html#104285">§6.6</a>. Not all modifiers are applicable to all kinds of interface declarations. The access modifiers protected and private pertain only to member interfaces within a directly enclosing class declaration <a href="classes.doc.html#246026">(§8.5)</a> and are discussed in <a href="classes.doc.html#247581">§8.5.1</a>. The access modifier static pertains only to member interfaces (<a href="classes.doc.html#246026">§8.5</a>, <a href="interfaces.doc.html#252566">§9.5</a>). A compile-time error occurs if the same modifier appears more than once in an interface declaration. <p>
<a name="30820"></a>
<h4>9.1.1.1 <code>abstract</code> Interfaces</h4>
<a name="30821"></a>
Every interface is implicitly <code>abstract</code>. This modifier is obsolete and should not be used in new programs.<p>
<a name="246350"></a>
<h4>9.1.1.2 <code>strictfp</code> Interfaces</h4>
<a name="251658"></a>
The effect of the <code>strictfp</code> modifier is to make all <code>float</code> or <code>double</code> expressions within the interface declaration be explicitly FP-strict <a href="expressions.doc.html#249198">(§15.4)</a>. <p>
<a name="252569"></a>
This implies that all nested types declared in the interface are implicitly <code>strictfp</code>.<p>
<a name="78598"></a>
<h3>9.1.2 Superinterfaces and Subinterfaces</h3>
<a name="78599"></a>
If an <code>extends</code> clause is provided, then the interface being declared extends each of the other named interfaces and therefore inherits the member types, methods, and constants of each of the other named interfaces. These other named interfaces are the <em>direct superinterfaces</em> of the interface being declared. Any class that <code>implements</code> the declared interface is also considered to implement all the interfaces that this interface <code>extends</code>.<p>
<ul><pre>
<em>ExtendsInterfaces:
</em> extends <em>InterfaceType
ExtendsInterfaces , InterfaceType
</em></pre></ul><a name="21599"></a>
The following is repeated from <a href="typesValues.doc.html#85587">§4.2</a> to make the presentation here clearer:<p>
<ul><pre>
<em>InterfaceType:
TypeName
</em></pre></ul><a name="152015"></a>
Each <em>InterfaceType </em>in the <code>extends</code> clause of an interface declaration must name an accessible interface type; otherwise a compile-time error occurs.<p>
<a name="246991"></a>
An interface <i>I directly depends</i> on a type <i>T </i>if <i>T</i> is mentioned in the <code>extends</code> clause of <i>I</i> either as a superinterface or as a qualifier within a superinterface name. An interface <i>I</i> depends on a reference type <i>T</i> if any of the following conditions hold:<p>
<ul><a name="246992"></a>
<li><i>I</i> directly depends on <i>T</i>.
<a name="246996"></a>
<li><i>I</i> directly depends on a class <i>C</i> that depends <a href="classes.doc.html#262560">(§8.1.3)</a> on <i>T</i>.
<a name="252497"></a>
<li><i>I</i> directly depends on an interface <i>J</i> that depends on <i>T</i> (using this definition recursively).
</ul><a name="252500"></a>
A compile-time error occurs if an interface depends on itself.<p>
<a name="78603"></a>
While every class is an extension of class <code>Object</code>, there is no single interface of which all interfaces are extensions. <p>
<a name="245858"></a>
The <em>superinterface </em>relationship is the transitive closure of the direct superinterface relationship. An interface <i>K</i> is a superinterface of interface <i>I</i> if either of the following is true:<p>
<ul><a name="236096"></a>
<li><i>K</i> is a direct superinterface of <i>I</i>.
<a name="236097"></a>
<li>There exists an interface <i>J</i> such that <i>K</i> is a superinterface of <i>J</i>, and <i>J</i> is a superinterface of <i>I</i>, applying this definition recursively.
</ul><a name="236428"></a>
Interface <i>I</i> is said to be a <em>subinterface </em>of interface <i>K</i> whenever <i>K</i> is a superinterface of <i>I</i>.<p>
<a name="236431"></a>
<h3>9.1.3 Interface Body and Member Declarations</h3>
<a name="78608"></a>
The body of an interface may declare members of the interface:<p>
<ul><pre>
<em>
InterfaceBody:
{ InterfaceMemberDeclarations<sub><i>opt</i></sub> }
InterfaceMemberDeclarations:
InterfaceMemberDeclaration
InterfaceMemberDeclarations InterfaceMemberDeclaration
InterfaceMemberDeclaration:
ConstantDeclaration
AbstractMethodDeclaration
ClassDeclaration
InterfaceDeclaration
<code>;</code></em>
</pre></ul><a name="253070"></a>
<strong></strong>The scope of the declaration of a member m declared in or inherited by an interface type I is the entire body of <i>I</i>, including any nested type declarations.<p>
<a name="17144"></a>
<h3>9.1.4 Access to Interface Member Names</h3>
<a name="17145"></a>
All interface members are implicitly <code>public</code>. They are accessible outside the package where the interface is declared if the interface is also declared <code>public</code> or <code>protected</code>, in accordance with the rules of <a href="names.doc.html#104285">§6.6</a>.<p>
<a name="32392"></a>
<h2>9.2 Interface Members</h2>
<a name="253076"></a>
The members of an interface are:<p>
<ul><a name="253077"></a>
<li>Those members declared in the interface.
<a name="253080"></a>
<li>Those members inherited from direct superinterfaces.
<a name="253081"></a>
<li>If an interface has no direct superinterfaces, then the interface implicitly declares a public abstract member method <i>m</i> with signature <i>s</i>, return type <i>r</i>, and <code>throws</code> clause <i>t</i> corresponding to each public instance method <i>m</i> with signature <i>s</i>, return type <i>r</i>, and <code>throws</code> clause <i>t</i> declared in <code>Object</code>, unless a method with the same signature, same return type, and a compatible <code>throws</code> clause is explicitly declared by the interface.
</ul><a name="252465"></a>
It follows that it is a compile-time error if the interface declares a method with the same signature and different return type or incompatible <code>throws</code> clause.<p>
<a name="245677"></a>
The interface inherits, from the interfaces it extends, all members of those interfaces, except for fields, classes, and interfaces that it hides and methods that it overrides.<p>
<a name="78642"></a>
<h2>9.3 Field (Constant) Declarations</h2>
<ul><pre>
<em>
ConstantDeclaration:
ConstantModifiers<sub><i>opt</i></sub> Type VariableDeclarators
ConstantModifiers:
ConstantModifier
<code> </code>ConstantModifier ConstantModifers<code> 
</code>
ConstantModifier: one of</em>
public static final
</pre></ul><a name="40575"></a>
Every field declaration in the body of an interface is implicitly <code>public</code>, <code>static</code>, and <code>final</code>. It is permitted to redundantly specify any or all of these modifiers for such fields.<p>
<a name="252384"></a>
If the interface declares a field with a certain name, then the declaration of that field is said to <em>hide</em> any and all accessible declarations of fields with the same name in superinterfaces of the interface.<p>
<a name="252453"></a>
It is a compile-time error for the body of an interface declaration to declare two fields with the same name.<p>
<a name="40725"></a>
It is possible for an interface to inherit more than one field with the same name <a href="classes.doc.html#40491">(§8.3.3.3)</a>. Such a situation does not in itself cause a compile-time error. However, any attempt within the body of the interface to refer to either field by its simple name will result in a compile-time error, because such a reference is ambiguous.<p>
<a name="40729"></a>
There might be several paths by which the same field declaration might be inherited from an interface. In such a situation, the field is considered to be inherited only once, and it may be referred to by its simple name without ambiguity. <p>
<a name="40720"></a>
<h3>9.3.1 Initialization of Fields in Interfaces</h3>
<a name="236695"></a>
Every field in the body of an interface must have an initialization expression, which need not be a constant expression. The variable initializer is evaluated and the assignment performed exactly once, when the interface is initialized <a href="execution.doc.html#44557">(§12.4)</a>.<p>
<a name="247455"></a>
A compile-time error occurs if an initialization expression for an interface field contains a reference by simple name to the same field or to another field whose declaration occurs textually later in the same interface.<p>
<a name="247101"></a>
Thus:
<blockquote><pre>interface Test {
float f = j;
int j = 1;
int k = k+1;
}
</pre></blockquote><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="247483"></a>
One subtlety here is that, at run time, fields 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="classes.doc.html#38010">(§8.3.2.1)</a>. This means, in particular, that these fields will never be observed to have their default initial values <a href="typesValues.doc.html#96595">(§4.5.5)</a>, even by devious programs. See <a href="execution.doc.html#44630">§12.4.2</a> and <a href="binaryComp.doc.html#45139">§13.4.8</a> for more discussion.
<p>
<a name="41024"></a>
If the keyword <code>this</code> <a href="expressions.doc.html#251519">(§15.8.3)</a> or the keyword <code>super</code> (<a href="expressions.doc.html#20860">15.11.2</a>, <a href="expressions.doc.html#20448">15.12</a>) occurs in an initialization expression for a field of an interface, then unless the occurrence is within the body of an anonymous class <a href="expressions.doc.html#252986">(§15.9.5)</a>, 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 <em>ambiguous member</em> results. Any use of this ambiguous member will result in a compile-time error. Thus in the example:<p>
<blockquote><pre>interface BaseColors {
int RED = 1, GREEN = 2, BLUE = 4;
}
interface RainbowColors extends BaseColors {
int YELLOW = 3, ORANGE = 5, INDIGO = 6, VIOLET = 7;
}
interface PrintColors extends BaseColors {
int YELLOW = 8, CYAN = 16, MAGENTA = 32;
}
interface LotsOfColors extends RainbowColors, PrintColors {
int FUCHSIA = 17, VERMILION = 43, CHARTREUSE = RED+90;
}
</pre></blockquote><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="247488"></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>
<em>AbstractMethodDeclaration:
AbstractMethodModifiers<sub><i>opt</i></sub> ResultType MethodDeclarator Throws<sub><i>opt</i></sub> ;
AbstractMethodModifiers:
AbstractMethodModifier
AbstractMethodModifiers AbstractMethodModifier
AbstractMethodModifier: one of</em>
public abstract
</pre></ul><a name="36046"></a>
The access modifier <code>public</code> is discussed in <a href="names.doc.html#104285">§6.6</a>. A compile-time error occurs if the same modifier appears more than once in an abstract method declaration.<p>
<a name="247503"></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.<p>
<a name="250791"></a>
Every method declaration in the body of an interface is implicitly <code>public</code>.<p>
<a name="247508"></a>
For compatibility with older versions of the Java platform, it is permitted but discouraged, as a matter of style, to redundantly specify the <code>abstract</code> modifier for methods declared in interfaces.
<a name="247493"></a>
<p>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 <code>static</code> methods cannot be <code>abstract</code>.<p>
<a name="245194"></a>
Note that a method declared in an interface must not be declared <code>strictfp</code> or <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>strictfp</code> or <code>native</code> or <code>synchronized</code> in a class that implements the interface.<p>
<a name="252440"></a>
It is a compile-time error for the body of an interface to declare, explicitly or implicitly, two methods with the same signature (name, number of parameters, and types of any parameters) <a href="classes.doc.html#38649">(§8.4.2)</a>. However, an interface may inherit several method with the same signature <a href="interfaces.doc.html#40247">(§9.4.1)</a>.<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 <em>override</em> any and all methods with the same signature in the superinterfaces of the interface.<p>
<a name="245222"></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="classes.doc.html#78323">(§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="40242"></a>
It is possible for an interface to inherit more than one method with the same signature <a href="classes.doc.html#38649">(§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.) 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 an interface, or one declared and one inherited) have the same name but different signatures, then the method name is said to be <em>overloaded</em>. 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="classes.doc.html#34484">§8.4.3.1</a>:<p>
<blockquote><pre>class BufferEmpty extends Exception {
BufferEmpty() { super(); }
BufferEmpty(String s) { super(s); }
}
class BufferError extends Exception {
BufferError() { super(); }
BufferError(String s) { super(s); }
}
public interface Buffer {
char get() throws BufferEmpty, BufferError;
}
public interface InfiniteBuffer extends Buffer {
char get() throws BufferError; // override
}
</pre></blockquote><a name="40735"></a>
<h4>9.4.3.2 Example: Overloading</h4>
<a name="40788"></a>
In the example code:<p>
<blockquote><pre>interface PointInterface {
void move(int dx, int dy);
}
interface RealPointInterface extends PointInterface {
void move(float dx, float dy);
void move(double dx, double dy);
}
</pre></blockquote><a name="252555"></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 non-<code>abstract</code> class that implements interface <code>RealPointInterface</code> must provide implementations of all three method signatures.<p>
<a name="252566"></a>
<h2>9.5 Member Type Declarations</h2>
<a name="245919"></a>
Interfaces may contain member type declarations <a href="classes.doc.html#246026">(§8.5)</a>. A member type declaration in an interface is implicitly <code>static</code> and public.<p>
<a name="245949"></a>
If a member type declared with simple name C is directly enclosed within the declaration of an interface with fully qualified name N, then the member type has the fully qualified name N.C. <p>
<a name="252418"></a>
If the interface declares a member type with a certain name, then the declaration of that field is said to <em>hide</em> any and all accessible declarations of member types with the same name in superinterfaces of the interface.<p>
<a name="239523"></a>
An interface may inherit two or more type declarations with the same name. A compile-time error occurs on any attempt to refer to any ambiguously inherited class or interface by its simple name. If the same type declaration is inherited from an interface by multiple paths, the class or interface is considered to be inherited only once; it may be referred to by its simple name without ambiguity.<p>
<hr>
<table border="0" width="100%">
<tr>
<td><a href="jTOC.doc.html">Contents</a> | <a href="classes.doc.html">Prev</a> | <a href="arrays.doc.html">Next</a> | <a href="jIX.fm.html">Index</a></td>
<td align=right><i>Java Language Specification</i><br>
<font size="-1">Second Edition</font></td></tr></table>
<i><a href="jcopyright.doc.html">Copyright</a> © 2000 Sun Microsystems, Inc.
All rights reserved</i>
<br>
Please send any comments or corrections to <a href="mailto:
[email protected]">
[email protected]</a>
</font>
</body></html>
