== Why is this an issue?

According to Joshua Bloch, author of "Effective Java":


____
The constant interface pattern is a poor use of interfaces. 


That a class uses some constants internally is an implementation detail.

Implementing a constant interface causes this implementation detail to leak into the class's exported API. It is of no consequence to the users of a class that the class implements a constant interface. In fact, it may even confuse them. Worse, it represents a commitment: if in a future release the class is modified so that it no longer needs to use the constants, it still must implement the interface to ensure binary compatibility. If a nonfinal class implements a constant interface,

all of its subclasses will have their namespaces polluted by the constants in the interface.

____

This rule raises an issue when an interface consists solely of fields, without any other members.


=== Noncompliant code example

[source,java]
----
interface Status {                      // Noncompliant
   int OPEN = 1;
   int CLOSED = 2;
}
----


=== Compliant solution

[source,java]
----
public enum Status {                    // Compliant
  OPEN,
  CLOSED;
}
----

or

[source,java]
----
public final class Status {             // Compliant
   public static final int OPEN = 1;
   public static final int CLOSED = 2;
}
----


ifdef::env-github,rspecator-view[]

'''
== Implementation Specification
(visible only on this page)

=== Message

Move constants defined in this interface to another class or enum.


'''
== Comments And Links
(visible only on this page)

=== on 23 Aug 2013, 08:38:39 Dinesh Bolkensteyn wrote:
Implemented by \http://jira.codehaus.org/browse/SONARJAVA-320

=== on 24 Aug 2013, 18:25:46 Ann Campbell wrote:
The advice here is to move to an enum, but an enum may not be appropriate for the constants involved. The typical advice (Bloch's advice too) appears to make the constants public static final in a class with a private constructor...?

=== on 24 Aug 2013, 18:29:43 Ann Campbell wrote:
I question the advice we're giving here...

=== on 26 Aug 2013, 04:43:19 Dinesh Bolkensteyn wrote:
hm, a utilitly class? Those aren't really nice to use - and is listed as last option (3) in Effective Java.


But indeed he suggests to 1) add constants such as Integer.MAX_VALUE and Integer.MIN_VALUE to the Integer class directly *or* 2) to move them to an enum if applicable

=== on 26 Aug 2013, 04:51:26 Dinesh Bolkensteyn wrote:
\[~ann.campbell.2] Does this updated issue message work for you? 'Move these constants either into an enum or to the implementing class.'

endif::env-github,rspecator-view[]
