Why are all fields in an interface implicitly static and final?

问题

I am just trying to understand why all fields defined in an Interface are implicitly static and final. The idea of keeping fields static makes sense to me as you can't have objects of an interface but why they are final (implicitly)?

Any one knows why Java designers went with making the fields in an interface static and final?

回答1:

An interface can't have behavior or state because it is intended to specify only an interaction contract, no implementation details. No behavior is enforced by not allowing method/constructor bodies or static/instance initializing blocks. No state is enforced by only allowing static final fields.Therefore, the Class can have a state (static state), but the instance state is not inferred by the interface.

BTW : A constant in Java is defined by a static final field (and by convention the name uses UPPER_CASE_AND_UNDERSCORES).

回答2:

Reason for being final

Any implementations can change value of fields if they are not defined as final. Then they would become a part of the implementation. An interface is a pure specification without any implementation.

Reason for being static

If they are static, then they belong to the interface, and not the object, nor the run-time type of the object.

回答3:

There are a couple of points glossed over here:

Just because fields in an interface are implicitly static final does not mean they must be compile-time constants, or even immutable. You can define e.g.

interface I {
  String TOKEN = SomeOtherClass.heavyComputation();
  JButton BAD_IDEA = new JButton("hello");
}

(Beware that doing this inside an annotation definition can confuse javac, relating to the fact that the above actually compiles to a static initializer.)

Also, the reason for this restriction is more stylistic than technical, and a lot of people would like to see it be relaxed.

回答4:

The fields must be static because they can't be abstract (like methods can). Because they can't be abstract, the implementers will not be able to logically provide the different implementation of the fields.

The fields must be final, I think, because the fields may be accessed by many different implementers allows they to be changeable might be problematic (as synchronization). Also to avoid it to be re-implemented (hidden).

Just my thought.

回答5:

I consider the requirement that the fields be final as unduly restrictive and a mistake by the Java language designers. There are times, e.g. tree handling, when you need to set constants in the implementation which are required to perform operations on an object of the interface type. Selecting a code path on the implementing class is a kludge. The workaround which I use is to define an interface function and implement it by returning a literal:

public interface iMine {
    String __ImplementationConstant();
    ...
}

public class AClass implements iMine {
    public String __ImplementationConstant(){
        return "AClass value for the Implementation Constant";
    }
    ...
}

public class BClass implements iMine {
    public String __ImplementationConstant(){
        return "BClass value for the Implementation Constant";
    }
    ...
}

However, it would be simpler, clearer and less prone to aberrant implementation to use this syntax:

public interface iMine {
    String __ImplementationConstant;
    ...
}

public class AClass implements iMine {
    public static String __ImplementationConstant =
        "AClass value for the Implementation Constant";
    ...
}

public class BClass implements iMine {
    public static String __ImplementationConstant =
        "BClass value for the Implementation Constant";
    ...
}

回答6:

Specification, contracts... The machine instruction for field access uses object address plus field offset. Since classes can implement many interfaces, there is no way to make non-final interface field to have the same offset in all classes that extend this interface. Therefore different mechanism for field access must be implemented: two memory accesses (get field offset, get field value) instead of one plus maintaining kind of virtual field table (analog of virtual method table). Guess they just didn't want to complicate jvm for functionality that can be easily simulated via existing stuff (methods).

In scala we can have fields in interfaces, though internally they are implemented as I explained above (as methods).

回答7:

static:

Anything (variable or method) that is static in Java can be invoked as Classname.variablename or Classname.methodname or directly. It is not compulsory to invoke it only by using object name.

In interface, objects cannot be declared and static makes it possible to invoke variables just through class name without the need of object name.

final:

It helps to maintain a constant value for a variable as it can't be overridden in its subclasses.

来源：https://stackoverflow.com/questions/1513520/why-are-all-fields-in-an-interface-implicitly-static-and-final

标签

java