Here is an example of a class using two constant variables
 from other classes:

class Math { final static double pi = java.lang.Math.atan( -1 )* -4; }
class Phys { final static double c_m_s = 299792458; }
public class Main
{ public static void main( final java.lang.String[] args )
 { java.lang.System.out.println( Math.pi );
   java.lang.System.out.println( Phys.c_m_s ); }}

 "import static" can be used to get rid of the class prefix:

import static java.lang.Math.PI;
import static java.awt.Color.RED;
public class Main
{ public static void main( final java.lang.String[] args )
 { java.lang.System.out.println( PI );
   java.lang.System.out.println( RED ); }}

 In Java, only interfaces have constants; classes have constant
 variables.

before you would have done something like.....

public interface ResumeConstants {
  public String HEADER = "Header";
}

public class ResumeWriter implements ResumeConstants {

   public void writeResume() {
      System.out.println(HEADER);
   }

}

Which you now know is not a good use of interfaces - its even thought of
as a anti-pattern.

So what to do....convert the interface into a class (as you have done),
and make the constants 'static'.

public class ResumeConstants {
   public static final String HEADER = "Header";
}

Now to make use of it...

public class ResumeWriter {

   public void writeResume() {
      System.out.println(ResumeConstants.HEADER);
   }

}

By making the constants static, it saves you having to instantiate the
ResumeConstants class in order to use its constants....e.g.

public class ResumeWriter {

   public void writeResume() {
      ResumeConstants  rc = new ResumeConstants();
      System.out.println( rc.HEADER );
   }

}

Now this business about making the constants class an abstract class....

If you try and use Inheritance you will always run into this type of
problem. This situation only ever calls for Delegation, not Inheritance.

In fact your designs will generally be much better if you 'favor
Delegation Over Inheritance' (nice and google-able term)

Even with Delegation, there's really only one valid reason for going the
Abstract class route, with these constants classes.... its to make it
difficult to instantiate the class like I just did above.  However,
making it Abstract merely prevents some one 'newing' the class directly,
it does not stop them creating a derived class and newing that instead.
 A better approach for be to make the default constructor 'private'.

As in...

public class ResumeConstants {
   public static final String HEADER = "Header";

   private ResumeConstants() {}
}

We sometimes do this if we think its a good thing to prevent this, but
there's always cases where we don't want to do this.

Going this route can actually leave you in as much trouble as having the
interface constants.  For example, say your constants were just that,
constants, but then we have a new business requirement that says we need
two or more different sets of constants, depending upon the user's
locale.  We'd be buggered if we used the approach above.

Instead, what we'd want to do it not directly access the constants
values, we want to get them via access methods (getters), but we'd want
to instantiate different ResumeUserLocaleConstants classes depending
upon locale, then use them in a polymorphic manner.

public interface UserLocaleDependantConstants {
   public String getHeader();
   public String getFooter();
   ...
}

public class UkUserConstants implements UserLocaleDependantConstants {
  // ... load UK values for the user constants...
}

public class USAUserConstants implements UserLocaleDependantConstants {
  // ... load USA values for the user constants...
}

public class FrenchUserConstants implements UserLocaleDependantConstants {
  // ... load French values for the user constants...
}

...

so we still have constants, just a different set are created at
application start up, or read from a server, or file, or....

HTH

Andrew

You have been misled.
Assuming your true objective is not fulfilled by an enumeration, and indeed
requires you to write code that uses constant expressions, the optimal
solution is the use of a final class - which is mutually exclusive from an
abstract class and is quite the opposite. The class should declare a private
constructor with a throws clause that specifies a single unchecked exception
(such as java.lang.UnsupportedOperationException). The constructor should
explicitly throw this exception as its only statement. Your constants should
be specified using public static final fields, which indeed should be
constants - and not finals, which is a common cause of confusion.

Implementing an interface to get the constants it defines is considered an
anti-pattern; you have at least one (and possibly many) instances of this
anti-pattern in your code. The required change is to:

1) Remove the "implements ResumeConstants" phrase from the class
declaration;
2) Qualify all references to constants:

where before you had:

A

you now need:

ResumeConstants.A

Hope that helps...

So far so good ;-)

It may, and in my experience nearly always does, make more sense to attach the
constants to the class to which they pertain.  I.e. while there can be reasons
to create a class just to hold constants, it is rarely necessary or desirable.
(And, frankly, in those rare cases it makes no difference at all whether you
use an abstract class or an interface -- it's a hack either way -- just don't
make the mistake of trying to inherit ("extends" or "implements") the class
containing the constants.  Use the constants, don't inherit them).

Classes that are clients of other classes can use the constants defined by the
other classes if those constants are public (which they should be /if/ they
are intended for use by other classes).

   -- chris