Is there a good use case for fields in interfaces today?

Question

Java allows fields in interfaces. This had some use before java 5. Do they have any good use case today?

Can Someone give me some good use cases where one would use fields in interfaces as opposed to many other ways to satisfy the same design requirement?

In fact interfaces an allow ambiguity and confusion in some situations. Take for eg. the following code:

Please note that I recognize that the problem of ambiguity has been discussed before and answered, but that is not my question. My question is noted in bold above. This is just an illustration of one potential side effect of fields in interfaces.

public class Sample implements Foo,Bar{

    public void print() {
        System.out.println("Hello"+name);//field name is ambiguous
    }

    public static void main(String[] args) {
        Sample mySample = new Sample();
        mySample.print();
    }

}

public interface Foo {
    String name = "foo";
}

public interface Bar{
    String name = "bar";
}

Answer 1

An interface is meant to define a contract, and constants are an implementation detail. If it makes sense that a number of implementations will share a constant, you can define it in an abstract class that will be used as a base class for the hierarchy. And if only one class is really tied to the constant, you should declare it there.

If you just want to group a certain number of constants together, you can define them in a final class:

final class Constants { //non extendable
    public static final double PI = 3.14d;
    public static final double E = 2.13d; //Can't remember the real value!

    private Constants() {} //non instantiable
}

You can also declare them in an enum when they are an enumeration (colours for example).

More about it in Effective Java Item #19 "Use interfaces only to define types", which concludes with:

In summary, interfaces should be used only to define types. They should not be used to export constants.

Bottom line, there is always a better way to define constants than in an interface.

Answer 2

If someone managed to give you a few good cases where one would use fields in interfaces as opposed to many other ways to satisfy the same design requirement, it would automatically justify using constants in interfaces.

In fact this is something we used to do in the very first versions of Java, many years back. Since then constants in interfaces have been abandoned in favor of static imports, which are also no perfect and classes of constants.

As stated in Java docs:

"So when should you use static import? Very sparingly! Only use it when you'd otherwise be tempted to declare local copies of constants, or to abuse inheritance (the Constant Interface Antipattern). In other words, use it when you require frequent access to static members from one or two classes."

Here are the drawbacks of using the constant interface pattern, according to Joshua Bloch (Bloch, Joshua, Effective Java, 2nd Edition, p. 98), as found in WikiPedia:

1. It pollutes the class namespace with read-only variables that may not be of use.
2. Contrary to the compile-time tactical utility of implementing a constants interface,the incidental run-time artifacts have little practical purpose (cf. marker interfaces which also have no methods but are useful at run-time).
3. If binary code compatibility is required in future releases, the constants interface must remain forever an interface (it cannot be converted into a class), even though it has not been used as an interface in the conventional sense.
4. Without an IDE that resolves where the constant are coming from, tracking it back to its containing class or interface can be time consuming.
5. A variable (representing an instance) of the interface is syntactically no more useful than the interface name itself (since it has no methods).