CHAPTER 9: Interface Declarations Previous
Previous
Java Language
Java Language
Index
Index
Next
Next

9.3 Field (Constant) Declarations

9.3.1 Initialization of Fields in Interfaces , 9.3.2 Examples of Field Declarations


ConstantDeclaration:

	ConstantModifiers Type VariableDeclarator

ConstantModifiers: one of

	public static final

Every field declaration in the body of an interface is implicitly public , static , and final . It is permitted, but strongly discouraged as a matter of style, to redundantly specify any or all of these modifiers for such fields.

A constant declaration in an interface must not include any of the modifiers synchronized , transient , or volatile , or a compile-time error occurs.

It is possible for an interface to inherit more than one field with the same name (S8.3.3.3). 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.

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.


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. The variable initializer is evaluated and the assignment performed exactly once, when the interface is initialized (S12.4).

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. Thus:


interface Test {
	float f = j;
	int j = 1;
	int k = k+1;
}

causes two compile-time errors, because j is referred to in the initialization of f before j is declared and because the initialization of k refers to k itself.

(One subtlety here is that, at run time, fields that are initialized with compile-time constant values are initialized first. This applies also to static final fields in classes (S8.3.2.1). This means, in particular, that these fields will never be observed to have their default initial values (S4.5.4), even by devious programs. See S12.4.2 and S13.4.8 for more discussion.)

If the keyword this (S15.7.2) or the keyword super (S15.10.2, S15.11) occurs in an initialization expression for a field of an interface, then a compile-time error occurs.


9.3.2 Examples of Field Declarations

The following example illustrates some (possibly subtle) points about field declarations.

9.3.2.1 Ambiguous Inherited Fields

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 ambiguous member results. Any use of this ambiguous member will result in a compile-time error. Thus in the example:


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;
}

the interface LotsOfColors inherits two fields named YELLOW . This is all right as long as the interface does not contain any reference by simple name to the field YELLOW . (Such a reference could occur within a variable initializer for a field.)

Even if interface PrintColors were to give the value 3 to YELLOW rather than the value 8 , a reference to field YELLOW within interface LotsOfColors would still be considered ambiguous.

9.3.2.2 Multiply Inherited Fields

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.

In the example in the previous section, the fields RED , GREEN , and BLUE are inherited by interface LotsOfColors in more than one way, through interface RainbowColors and also through interface PrintColors , but the reference to field RED in interface LotsOfColors is not considered ambiguous because only one actual declaration of the field RED is involved.

Top© 1996 Sun Microsystems, Inc. All rights reserved.