An interface is declared using the keyword interface, giving the interface a name and listing the interface members between curly braces.
An interface can declare three kinds of members:
>constants (fields)
>methods
>nested classes and interfaces
All interface members are implicitly public, but, by convention, the public modifier is omitted. Having non-public members in an interface would make little sense; where it does make sense you can use the accessibility of the interface itself to control access to the interface members.
Interface Constants
An interface can declare named constants. These constants are defined as fields but are implicitly public, static, and finalagain, by convention, the modifiers are omitted from the field declarations.
Because interfaces contain no implementation details, they cannot define normal fieldssuch a definition would be dictating implementation policy to the classes that choose to implement the interface. Interfaces can define named constants because these are useful in the design of types. For example, an interface that had differing levels of verbosity in its contract might have the following:
interface Verbose
{
int SILENT = 0;
int TERSE = 1;
int NORMAL = 2;
int VERBOSE = 3;
void setVerbosity(int level);
int getVerbosity();
}
SILENT, TERSE, NORMAL, and VERBOSE can be passed to the setVerbosity method, giving names to constant values that represent specific meanings.
Interface Methods
The methods declared in an interface are implicitly abstract because no implementation is, or can be, given for them. For this reason the method body is simply a semicolon after the method header. By convention, the abstract modifier on the method declaration is omitted.
Extending Interfaces
Interfaces can be extended using the extends keyword. Interfaces, unlike classes, can extend more than one other interface:
public interface SerializableRunnable
extends java.io.Serializable, Runnable
{
// ...
}
The SerializableRunnable interface extends both java.io.Serializable and Runnable, which means that all methods and constants defined by those interfaces are now part of the SerializableRunnable contract, together with any new methods and constants it defines. The interfaces that are extended are the superinterfaces of the new interface and the new interface is a subinterface of its superinterfaces.
Because interfaces support multiple inheritance, the inheritance graph can contain multiple paths to the same superinterface. This means that constants and methods can be accessed in different ways. However, because interfaces define no implementation of methods, and provide no per-object fields, there are no issues regarding the semantics of this form of multiple inheritance.
In the subinterface and in any object implementing the subinterface, any reference to the constant using its simple name will refer to the constant defined in the subinterface. The inherited constant can still be accessed with the qualified name of the constant, that is, the interface name followed by dot and then the constant namethe usual way of referring to static members.
interface X
{
int val = 1;
}
interface Y extends X
{
int val = 2;
int sum = val + X.val;
}
Interface Y has two constants: val and sum. From inside Y, to refer to the hidden val in its superinterface you must qualify it as X.val. Externally, you can access the constants of Y by using the normal static forms of Y.val and Y.sum, and of course you can access X's val constant by using X.val.
These rules are, of course, identical to those concerning the inheritance of static fields in classes.
When a class implements Y you can access the constants in Y as though they were constants declared in the class. For example, given
class Z implements Y { }
you can do
System.out.println("Z.val=" + Z.val + ", Z.sum=" + Z.sum);
but there is no way to refer to X.val via Z. However, given an instance of Z you can use an explicit cast to access X.val:
Z z = new Z();
System.out.println("z.val=" + z.val +
", ((Y)z).val=" + ((Y)z).val +
", ((X)z).val=" + ((X)z).val);
which prints out
z.val=2, ((Y)z).val=2, ((X)z).val=1
as you would expect. Again these are the same rules that apply to static fields in extended classesit doesn't matter whether a class inherits a static field from a superclass or a superinterface.
While all these rules are necessary from a language perspective, they have little practical consequencethere are few reasons to hide existing fields, and all accesses to static fields, whether class or interface, should be via the name of the type in which that field is declared.
If an interface inherits two or more constants with the same name, then any simple reference to the constant is ambiguous and results in a compile-time error. For example, given the previous interface declarations and the following:
interface C
{
String val = "Interface C";
}
interface D extends X, C { }
then the expression D.val is ambiguousdoes it mean the integer val or the String reference val? Inside D you would have to explicitly use X.val or C.val.
A class that implements more than one interface, or that extends a class and implements one or more interfaces, can experience the same hiding and ambiguity issues as an interface that extends more than one interface. The class's own static fields can hide the inherited fields of the interfaces it implements or the class it extends, and simple references to multiply-inherited non-hidden fields will be ambiguous.
An interface can declare three kinds of members:
>constants (fields)
>methods
>nested classes and interfaces
All interface members are implicitly public, but, by convention, the public modifier is omitted. Having non-public members in an interface would make little sense; where it does make sense you can use the accessibility of the interface itself to control access to the interface members.
Interface Constants
An interface can declare named constants. These constants are defined as fields but are implicitly public, static, and finalagain, by convention, the modifiers are omitted from the field declarations.
Because interfaces contain no implementation details, they cannot define normal fieldssuch a definition would be dictating implementation policy to the classes that choose to implement the interface. Interfaces can define named constants because these are useful in the design of types. For example, an interface that had differing levels of verbosity in its contract might have the following:
interface Verbose
{
int SILENT = 0;
int TERSE = 1;
int NORMAL = 2;
int VERBOSE = 3;
void setVerbosity(int level);
int getVerbosity();
}
SILENT, TERSE, NORMAL, and VERBOSE can be passed to the setVerbosity method, giving names to constant values that represent specific meanings.
Interface Methods
The methods declared in an interface are implicitly abstract because no implementation is, or can be, given for them. For this reason the method body is simply a semicolon after the method header. By convention, the abstract modifier on the method declaration is omitted.
Extending Interfaces
Interfaces can be extended using the extends keyword. Interfaces, unlike classes, can extend more than one other interface:
public interface SerializableRunnable
extends java.io.Serializable, Runnable
{
// ...
}
The SerializableRunnable interface extends both java.io.Serializable and Runnable, which means that all methods and constants defined by those interfaces are now part of the SerializableRunnable contract, together with any new methods and constants it defines. The interfaces that are extended are the superinterfaces of the new interface and the new interface is a subinterface of its superinterfaces.
Because interfaces support multiple inheritance, the inheritance graph can contain multiple paths to the same superinterface. This means that constants and methods can be accessed in different ways. However, because interfaces define no implementation of methods, and provide no per-object fields, there are no issues regarding the semantics of this form of multiple inheritance.
In the subinterface and in any object implementing the subinterface, any reference to the constant using its simple name will refer to the constant defined in the subinterface. The inherited constant can still be accessed with the qualified name of the constant, that is, the interface name followed by dot and then the constant namethe usual way of referring to static members.
interface X
{
int val = 1;
}
interface Y extends X
{
int val = 2;
int sum = val + X.val;
}
Interface Y has two constants: val and sum. From inside Y, to refer to the hidden val in its superinterface you must qualify it as X.val. Externally, you can access the constants of Y by using the normal static forms of Y.val and Y.sum, and of course you can access X's val constant by using X.val.
These rules are, of course, identical to those concerning the inheritance of static fields in classes.
When a class implements Y you can access the constants in Y as though they were constants declared in the class. For example, given
class Z implements Y { }
you can do
System.out.println("Z.val=" + Z.val + ", Z.sum=" + Z.sum);
but there is no way to refer to X.val via Z. However, given an instance of Z you can use an explicit cast to access X.val:
Z z = new Z();
System.out.println("z.val=" + z.val +
", ((Y)z).val=" + ((Y)z).val +
", ((X)z).val=" + ((X)z).val);
which prints out
z.val=2, ((Y)z).val=2, ((X)z).val=1
as you would expect. Again these are the same rules that apply to static fields in extended classesit doesn't matter whether a class inherits a static field from a superclass or a superinterface.
While all these rules are necessary from a language perspective, they have little practical consequencethere are few reasons to hide existing fields, and all accesses to static fields, whether class or interface, should be via the name of the type in which that field is declared.
If an interface inherits two or more constants with the same name, then any simple reference to the constant is ambiguous and results in a compile-time error. For example, given the previous interface declarations and the following:
interface C
{
String val = "Interface C";
}
interface D extends X, C { }
then the expression D.val is ambiguousdoes it mean the integer val or the String reference val? Inside D you would have to explicitly use X.val or C.val.
A class that implements more than one interface, or that extends a class and implements one or more interfaces, can experience the same hiding and ambiguity issues as an interface that extends more than one interface. The class's own static fields can hide the inherited fields of the interfaces it implements or the class it extends, and simple references to multiply-inherited non-hidden fields will be ambiguous.
