9.4.2

Overloading

INTERFACES

declaration must not have a

throws

 clause that conflicts ( 8.4.4) with that of any

method that it overrides; otherwise, a compile time error occurs.

Methods are overridden on a signature by signature basis. If, for example, an

interface declares two

public

 methods with the same name, and a subinterface

overrides one of them, the subinterface still inherits the other method.

An interface inherits from its direct superinterfaces all methods of the super 

interfaces that are not overridden by a declaration in the interface.

It is possible for an interface to inherit more than one method with the same

signature ( 8.4.2). 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

void

. (The

throws

 clauses

do not cause errors in this case.)

There might be several paths by which the same method declaration is inher 

ited from an interface. This fact causes no difficulty and never of itself results in a

compile time error.

9.4.2   Overloading

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

overloaded

. 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

throws

 clauses

of two methods with the same name but different signatures.

9.4.3   Examples of Abstract Method Declarations

The following examples illustrate some (possibly subtle) points about abstract

method declarations.

9.4.3.1

Example: Overriding

Methods declared in interfaces are

abstract

 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

 8.4.3.1:

190