interface类型-CSDN博客

接口可使用的修饰符如下：

InterfaceModifier: one of
    Annotation public protected private
    abstract static strictfp

接口中可声明的一些成员：

InterfaceMemberDeclaration:
ConstantDeclaration
AbstractMethodDeclaration
ClassDeclaration 
InterfaceDeclaration

The modifier static pertains only to member interfaces (§8.5.1, §9.5), not to top level interfaces (§7.6).

The access modifiers protected and private pertain only to member interfaces within a directly enclosing class or enum declaration (§8.5.1).

9.1.1.2. `strictfp` Interfaces

The effect of the strictfp modifier is to make all float or double expressions within the interface declaration be explicitly FP-strict (§15.4).

This implies that all nested types declared in the interface are implicitly strictfp.

It is a compile-time error to refer to a type parameter of an interface I anywhere in the declaration of a field or type member of I.

9.1.3. Superinterfaces and Subinterfaces

If an extends 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.

Given a (possibly generic) interface declaration for I<F₁,...,F_n>(n ≥ 0), the direct superinterfaces of the interface typeI<F₁,...,F_n> are the types given in the extends clause of the declaration of I if an extends clause is present.

Let I<F₁,...,F_n> (n > 0), be a generic interface declaration. The direct superinterfaces of the parameterized interface type I<T₁,...,T_n>, where T_i (1 ≤ i ≤ n) is a type, are all types J<U₁θ,...,U_k θ>, where J<U₁,...,U_k> is a direct superinterface ofI<F₁,...,F_n>, and θ is the substitution [F₁:=T₁,...,F_n:=T_n].

9.2. Interface Members

The members of an interface are:

Those members declared in the interface.
Those members inherited from direct superinterfaces.
If an interface has no direct superinterfaces, then the interface implicitly declares a public abstract member method m with signature s, return type r, and throws clause t corresponding to each public instance method m with signature s, return type r, and throws clause t declared in Object, unless a method with the same signature, same return type, and a compatible throws clause is explicitly declared by the interface.

It is a compile-time error if the interface explicitly declares such a method m in the case where m is declared to be final in Object.

It follows that is a compile-time error if the interface declares a method with a signature that is override-equivalent (§8.4.2) to a public method of Object, but has a different return type or incompatible throwsclause.

The interface inherits, from the interfaces it extends, all members of those interfaces, except for (a) fields, classes, and interfaces that it hides and (b) methods that it overrides (§9.4.1).

Fields, methods, and member types of an interface type may have the same name, since they are used in different contexts and are disambiguated by different lookup procedures (§6.5). However, this is discouraged as a matter of style.

9.3.1. Initialization of Fields in Interfaces

Every field in the body of an interface must have an initialization expression, which need not be a constant expression (§15.28), or a compile-time error occurs.

It is a compile-time error 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.

9.4. Abstract Method Declarations

It is a compile-time error if a method declared in an interface is declared static, because staticmethods cannot be abstract.

It is a compile-time error if a method declared in an interface is strictfp or native or synchronized, because those keywords describe implementation properties rather than interface properties.

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 refine the return type or 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):

9.4.1.2. Requirements in Overriding

The relationship between the return type of an interface method and the return types of any overridden interface methods is specified in §8.4.8.3.

The relationship between the throws clause of an interface method and the throws clauses of any overridden interface methods are specified in §8.4.8.3.

The relationship between the signature of an interface method and the signatures of overridden interface methods are specified in §8.4.8.3.

9.5. Member Type Declarations

An interface inherits from its direct superinterfaces all the non-private member types of the superinterfaces that are both accessible to code in the interface and not hidden by a declaration in the interface.

9.6.1. Annotation Type Elements

Each method declaration in an annotation type declaration defines an element of the annotation type.

Annotation types can have zero or more elements. An annotation type has no elements other than those defined by the methods it explicitly declares.

AnnotationTypeElementDeclaration:
    AbstractMethodModifiersopt Type Identifier ( ) Dimsopt DefaultValueopt ;
    ConstantDeclaration
    ClassDeclaration
    InterfaceDeclaration
    EnumDeclaration
    AnnotationTypeDeclaration
    ;

DefaultValue:
    default ElementValue

By virtue of the AnnotationTypeElementDeclaration syntax, a method declaration in an annotation type declaration cannot have any formal parameters or type parameters, or a throws clause.

By convention, no AbstractMethodModifiers should be present on an annotation type element except for annotations.

It is a compile-time error if the return type of a method declared in an annotation type is not one of the following: a primitive type, String, Class, any parameterized invocation of Class, an enum type (§8.9), an annotation type, or an array type (§10) whose element type is one of the preceding types.

This specification precludes elements whose types are nested arrays. For example, this annotation type declaration is illegal:

@interface Verboten {
    String[][] value();
}

It is a compile-time error if any method declared in an annotation type has a signature that is override-equivalent to that of any public or protected method declared in class Object or in the interface java.lang.annotation.Annotation.

It is a compile-time error if an annotation type declaration T contains an element of type T, either directly or indirectly.

For example, this is illegal:

@interface SelfRef { SelfRef value(); }

and so is this:　

@interface Ping { Pong value(); }
@interface Pong { Ping value(); }

Example 9.6.2-3. Complex Annotation Type Declaration

The following annotation type declaration shows a Class annotation whose value is restricted by a bounded wildcard:

interface Formatter {}

// Designates a formatter to pretty-print the annotated class
@interface PrettyPrinter {
    Class<? extends Formatter> value();
}

class GorgeousFormatter implements Formatter { ... }

@PrettyPrinter(GorgeousFormatter.class)
public class Petunia { ... }

// Illegal; String is not a subtype of Formatter
@PrettyPrinter(String.class)
public class Begonia { ... }

Here is an example of a complex annotation type, that is, an annotation type that contains one or more elements whose types are also annotation types.

/**
 * A person's name.  This annotation type is not designed
 * to be used directly to annotate program elements, but to
 * define elements of other annotation types.
 */
@interface Name {
    String first();
    String last();
}
/**
 * Indicates the author of the annotated program element.
 */
@interface Author {
    Name value();
}
/**
 * Indicates the reviewer of the annotated program element.
 */
@interface Reviewer {
    Name value();
}

可以这样使用：

@Author(@Name(first = "Joe", last = "Hacker"))
public class BitTwiddle { ... }

9.7. Annotations

An annotation is a modifier consisting of the name of an annotation type (§9.6) and zero or more element-value pairs, each of which associates a value with a different element of the annotation type.

The purpose of an annotation is simply to associate information with the annotated program element.

Annotations must contain an element-value pair for every element of the corresponding annotation type, except for those elements with default values, or a compile-time error occurs.

Annotations may, but are not required to, contain element-value pairs for elements with default values.

Annotations may be used as modifiers in any declaration, whether package (§7.4.1), class (§8.1.1) (including enums (§8.9)), interface (§9.1.1) (including annotation types (§9.6)), field (§8.3.1, §9.3), method (§8.4.3, §9.4), formal parameter (§8.4.1), constructor (§8.8.3), or local variable (§14.4.1).

Annotations may also be used on enum constants. Such annotations are placed immediately before the enum constant they annotate.

It is a compile-time error if a declaration is annotated with more than one annotation for a given annotation type.

Annotations are conventionally placed before all other modifiers, but this is not a requirement; they may be freely intermixed with other modifiers.

9.7.1. Normal Annotations

A normal annotation is used to annotate a program element.

NormalAnnotation:
    @ TypeName ( ElementValuePairsopt )

ElementValuePairs:
    ElementValuePair
    ElementValuePairs , ElementValuePair

ElementValuePair:
    Identifier = ElementValue

ElementValue:
    ConditionalExpression
    Annotation
    ElementValueArrayInitializer

ElementValueArrayInitializer:
    { ElementValuesopt ,opt }

ElementValues:
    ElementValue
    ElementValues , ElementValue

The TypeName names the annotation type corresponding to the annotation.

Note that the at-sign (@) is a token unto itself. Technically it is possible to put whitespace between it and the TypeName, but this is discouraged as a matter of style.

It is a compile-time error if TypeName does not name an annotation type that is accessible (§6.6) at the point where the annotation is used.

The Identifier in an ElementValuePair must be the simple name of one of the elements (i.e. methods) of the annotation type identified by TypeName; otherwise, a compile-time error occurs.

The return type of this method defines the element type of the element-value pair.

An ElementValueArrayInitializer is similar to a normal array initializer (§10.6), except that annotations are permitted in place of expressions.