An interface can declare named constants. These constants are defined as fields but are implicitly public, static, and final—again, by convention, the modifiers are omitted from the field declarations. These fields must also have initializers—blank finals are not permitted. Annotations can also be applied to the fields—see Chapter 15.

Because interfaces contain no implementation details, they cannot define normal fields—such 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. In this particular case, the verbosity levels could be more effectively represented as the constants of an enumeration type nested within the Verbose interface. Enumeration types are discussed in Chapter 6.

If you need shared, modifiable data in your interface you can achieve this by using a named constant that refers to an object that holds the data. A nested class is good for defining that object, so we defer an example until Chapter 5.

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.

No other method modifiers are permitted on an interface method declaration, except for annotations—see Chapter 15. They are implicitly public and so can have no other access modifier. They cannot have modifiers that define implementation characteristics—such as native, synchronized, or strictfp—because an interface does not dictate implementation, and they cannot be final because they haven't been implemented yet. Of course, the implementation of these methods within a specific class can have any of these modifiers. Interface methods can never be static because static methods can't be abstract.

An interface declaration can be preceded by interface modifiers:

When multiple modifiers are applied to the same interface declaration, we recommend using the order listed above.

An extended interface inherits all the constants declared in its superinterfaces. If an interface declares a constant of the same name as an inherited constant, regardless of their types, then the new constant hides the inherited one; this is the same hiding of fields described in “Hiding Fields” on page 86. 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 name—the 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 classes—it 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 consequence—there 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 ambiguous—does 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.

A subinterface inherits all the methods declared in its superinterfaces. If a declared method in a subinterface has the same signature (name and parameter list) as an inherited method and the same, or covariant, return type, then the new declaration overrides any and all existing declarations. Overriding in interfaces, unlike overriding in classes, has no semantic effect—the interface effectively contains multiple declarations of the same method, but in any one implementing class there can only be one implementation of that method.

Similarly, if an interface inherits more than one method with the same signature, or if a class implements different interfaces containing a method with the same signature, there is only one such method. The implementation of this method is ultimately defined by the class implementing the interfaces, and there is no ambiguity there. If the methods have the same signature but different return types, then one of the return types must be a subtype of all the others, otherwise a compile-time error occurs. The implementation must define a method that returns that common subtype.

The real issue is whether a single implementation of the method can honor all the contracts implied by that method being part of the different interfaces. This may be an impossible requirement to satisfy in some circumstances. For example:

interface CardDealer {
    void draw();          // flip top card
    void deal();          // distribute cards
    void shuffle();
}
interface GraphicalComponent {
    void draw();          // render on default device
    void draw(Device d);  // render on 'd'
    void rotate(int degrees);
    void fill(Color c);
}
interface GraphicalCardDealer
    extends CardDealer, GraphicalComponent { }

Here it is difficult to write an implementation of draw() that can satisfy the two different contracts independently. If you try to satisfy them simultaneously, you are unlikely to achieve the desired results: flipping a card each time the screen gets repainted.

As with overriding in class extension, the overriding method is not permitted to throw more checked exceptions than the method it overrides. If two or more method declarations are inherited, without overriding, and differ in the exceptions they throw, then the implementation of that method must satisfy all the throws clauses of those declarations. Again the main issue is whether such distinct methods can have a single implementation that honors all contracts. We look further at the issues of overriding and exception throwing in Chapter 12.

If a declared method has the same name but different parameters from an inherited method, then the declared method is an overloaded form of the inherited method. The eventual class implementation will provide a method body for each of the overloaded forms.

If a declared method differs only in return type from an inherited method, or if two inherited methods differ only in return type where one type is not a subtype of the other, you will get a compile-time error.

Interfaces describe contracts in a pure, abstract form, but an interface is interesting only if a class implements it.

Some interfaces are purely abstract—they do not have any useful general implementation but must be implemented afresh for each new class. Most interfaces, however, may have several useful implementations. In the case of our Attributed interface, we can imagine several possible implementations that use various strategies to store a set of attributes.

One strategy might be simple and fast when only a few attributes are in a set; another one might be optimized for attribute sets that are queried more often than they are changed; yet another design might be optimized for sets that change frequently. If there were a package of various implementations for the Attributed interface, a class might choose to implement the Attributed interface through any one of them or through its own implementation.

As an example, here is a simple implementation of Attributed that uses the utility java.util.HashMap class. The class AttributedImpl declares that it implements the interface Attributed, so the class must implement all the interface's methods. AttributedImpl implements the methods using a HashMap, described in “HashMap” on page 590. Later, this implementation is used to implement the Attributed interface for a specific set of objects to which you would want to add attributes. First, here is the AttributedImpl class:

import java.util.*;

class AttributedImpl implements Attributed, Iterable<Attr> {
    protected Map<String, Attr> attrTable =
        new HashMap<String, Attr>();

    public void add(Attr newAttr) {
        attrTable.put(newAttr.getName(), newAttr);
    }

    public Attr find(String name) {
        return attrTable.get(name);
    }

    public Attr remove(String name) {
        return attrTable.remove(name);
    }

    public Iterator<Attr> attrs() {
        return attrTable.values().iterator();
    }

    public Iterator<Attr> iterator() {
        return attrs();
    }
}

The initializer for attrTable creates a HashMap object to hold attributes. This HashMap object does most of the actual work. The HashMap class uses the key object's hashCode method to hash any object it is given as a key. No explicit hash method is needed since String already provides a good hashCode implementation.

When a new attribute is added, the Attr object is stored in the hash map under its name, and then you can easily use the hash map to find and remove attributes by name. The attrs method returns the Iterator for the hash map's values, giving access to all the attributes of the current object.

We chose to make this implementation of Attributed also implement Iterable<Attr>, as the attributes are the only things an AttributedImpl contains. To do this, we had to define the iterator method to return the same value as the attrs method.

You can use an implementing class like AttributedImpl by simply extending the class. This is the simplest tool when it is available because all the methods and their implementations are inherited. But if you need to support more than one interface or extend a different class, you must use a different approach. The most common approach is to create an object of an implementing class and forward all the methods of the interface to that object, returning any values—this is often called composition.

In composition and forwarding, each method in the class that is inherited from the interface invokes the implementation from another object and returns the result. Here is an implementation of the Attributed interface that uses an AttributedImpl object to build an attributed version of our previously defined celestial body class Body:

import java.util.Iterator;

class AttributedBody extends Body
    implements Attributed
{
    private AttributedImpl attrImpl = new AttributedImpl();

    public AttributedBody() {
        super();
    }

    public AttributedBody(String name, Body orbits) {
        super(name, orbits);
    }

    // Forward all Attributed methods to the attrImpl object

    public void add(Attr newAttr)
        { attrImpl.add(newAttr); }
    public Attr find(String name)
        { return attrImpl.find(name); }
    public Attr remove(String name)
        { return attrImpl.remove(name); }
    public Iterator<Attr> attrs()
        { return attrImpl.attrs(); }
}

The declaration that AttributedBody extends Body and implements Attributed defines the contract of AttributedBody. The implementations of all Body's methods are inherited from the Body class itself. Each method of Attributed is implemented by forwarding the invocation to the AttributedImpl object's equivalent method, returning its value (if any). This also means that you must add a field of type AttributedImpl to use in the forwarding methods and initialize that field to refer to an AttributedImpl object.

Forwarding is both straightforward and much less work than implementing Attributed from scratch. Forwarding also enables you to quickly change the implementation you use, should a better implementation of Attributed become available at some future date. However, forwarding must be set up manually and that can be tedious and sometimes error prone.