Some time ago I have read two different books and each of them gives totally different answer for the question if it is a good pattern to define constant values in the interface (in java).

So I am curious of your opinions with some reasonable arguments.

Is it a good habit/ pattern to define constant values in interfaces in java?

Is it generally good, generally bad or it depends?

  • you might look into this stackoverflow.com/questions/2659593/…
    – Paritosh
    Nov 8, 2012 at 11:34
  • yes i looked there and i also added a comment/ question. so you can take a look there also?
    – Łukasz Rzeszotarski
    Nov 8, 2012 at 11:45
  • 1
    If all those classes use some similar constants and methods, why not extend an abstract class instead? If not, Effective Java puts a strong case in for Enums.
    – Eric P.
    Nov 8, 2012 at 14:03
  • @E-Man assume that we have A (extends) B, C (extends) D, B and D are from external library (I cannot create common super class for them). So because that we don't have multiple inheritance it is not possible to make an abstract super class for them. In this case the intention is not to create the interface as a place for storing constant values (what I also consider as antipattern), but the interface is rather something which gives some common behaviour and features (constant values) for my classes A and C
    – Łukasz Rzeszotarski
    Nov 8, 2012 at 14:26

2 Answers 2


Item 19 of Effective Java 2nd ed. recommends the following:

If the constants are strongly tied to an existing class or interface, you should add them to the class or interface...If the constants are best viewed as members of an enumerated type, you should export them with an enum type. Otherwise, you should export the constants with a noninstantiable utility class.

public class SomeConstants {
    private SomeConstants() { } // Private default constructor

    public static final double WEIRD_NUMBER = 123456.7;
    public static final int ANOTHER_NUMBER = 5;

Edit: As with all things, exceptions exist. This case (constants and some methods need to be shared by external types) might be a good argument for using an interface in this manner.

  • I wouldn't bother with the private constructor. Since there's no reason anyone would ever instantiate the class, why prevent it? Nov 8, 2012 at 16:15
  • 3
    @kevincline to make it clear to any other programmer that there are no instances where you would (or could) instantiate the class.
    – user40980
    Nov 8, 2012 at 19:34
  • @MichaelT: Isn't that already obvious from the class name, and the fact that all the members and methods are static? Nov 8, 2012 at 20:44
  • If a public constructor isn't part of the API, then I don't see a real downside to enforcing that by using a private one.
    – Eric P.
    Nov 8, 2012 at 21:11
  • @E-Man: the downside is more noise in the code to defend against a non-problem. If your team is likely to instantiate SomeConstants, then you will have much bigger problems that no amount of defensive coding can prevent. Nov 13, 2012 at 18:01

I use constants in interface to have the same references when my programms have internal parameters, about all when thoses constants may change in next version,
and I use enum otherwhere.

I have also a interface of usual constant by default, those constants are use if no other environment parameter given by some myFile.properties overwrite them.

Effective Java (2008) from Joshua Bloch give many tips about it.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.