How to implement Constants in Java

Question

Is this a good idea, to group constants in classes inside Constants class container like

public final class Constants {
  public final class File {
    public static final int MIN_ROWS = 1;
    public static final int MAX_ROWS = 1000;

    private File() {}
  }

  public final class DB {
    public static final String name = "oups";

    public final class Connection() {
      public static final String URL = "jdbc:tra-ta-ta";
      public static final String USER = "testUser";
      public static final String PASSWORD = "testPassword";

      private Connection() {}
    }

    private DB() {}
  }

  private Constants() {}
}

It allows to use Constants.DB.Connection.URL instead of DbConnectionConstants.URL.

Grouping sometimes helps with clarity. `public class Constants { private static final class KeyOffsets { public static final int QTY = 0; //8-bytes (long) public static final int PRICE = 8; //8-bytes (long) } public static class Offset { public static final int Action = 16; } }` — , Jan 10 '12 at 20:21
Possible dup of http://stackoverflow.com/questions/66066/what-is-the-best-way-to-implement-constants-in-java — JustinKSU, Jan 10 '12 at 20:41
AS I PREFER NEITHER MY CODE SHOUTING AT ME NOR PROGRAMMING IN COBOL, I TEND TO USE PascalCase FOR MY CONSTANTS!!!!!!! — yeoman, Oct 24 '18 at 12:41

score 9 · Answer 1 · answered Jan 10 '12 at 20:13

9

I generally prefer to put constants in the class where they belong. For example, the file constants could be in FileManager (or something like that), where they are used. The connection constants could be in your DBUtil class, where they are used.

Think about the JDK. Does it have a gigantic Constants class? No. The constants used by (and with) BorderLayout are in the class BorderLayout. The constants used by (and with) JOptionPane are in JOptionPane.

answered Jan 10 '12 at 20:13

JB Nizet

678,734
91
1,224
1,255

If a constant is only used once in a centralized place, I agree with this approach. However, it might not work in more complicated implementations. – JustinKSU Jan 10 '12 at 20:16

score 2 · Answer 2 · answered Jan 10 '12 at 20:28

Advantages:

You get a nice "path" to your constants.
You might get a cross-code constants convention, if colleages follow the guidance.

Disadvantages:

With many constants and many "domains" of constants, that class might get too cumbersome to handle.
It's not intuitive. It reminds me more of Ant properties than java constants.
It prevents modularization of your code. Say you want to separate your DB connecting package and File handling package to different jars which might be used by different applications. It is redundant to deliver your DB management jar with file handling constants. And you can easily get to have many such modules.

In conclusion, it's something that might be handy when you write just some little application for your own self. Generally, it is not a good practice.

score 1 · Answer 3 · answered Jan 10 '12 at 20:11

1

Use Enum http://docs.oracle.com/javase/tutorial/java/javaOO/enum.html

each JVM will have only one copy of enum object

answered Jan 10 '12 at 20:11

ligerdave

714
2
6
13

How do you store a database server password in an enum? – Edward Thomson Jan 10 '12 at 20:41
INSTANCE;public final PASSWORD="abcd"; – ligerdave Jan 11 '12 at 02:33
Even if that would work, it's an abuse of an `enum`. Further, your argument suggests that constant `String`s aren't interned by the JVM, which they are. – Edward Thomson Jan 11 '12 at 14:58
you are correct. there will be only one copy of the String object. using enum is just a way to encapsulate things. what do you think about using enum as a way to implement singleton pattern? do you think that's an abuse of usage? – ligerdave Jan 11 '12 at 21:17

JustinKSU · Answer 4 · 2012-01-10T21:02:29.103

1

You could always use a .properties file in the classpath using the foo.bar.baz notation. This would make it easier to change the values without recompiling. The Spring framework provides utilities to help refresh the values on the fly.

However, I agree with @JB Nizet and @yair that keeping with with the Class most associated with the constant is a better idea.

edited Jan 10 '12 at 21:02

answered Jan 10 '12 at 20:40

JustinKSU

4,875
2
29
51

score -3 · Answer 5 · answered Jan 10 '12 at 20:23

-3

You can use abstract for the constants class too, even better than the private constructor. If you use an interface it would be usable outside the class hierarchy and one may simply use implements though hiding the origin (interface name).

One issue though. If you import a class only for a constant, the compiler may remove the import in the .class and fill in the constant itself. If one later changes the constant's value, the using class will not automatically recompile, and maintain the old value.

answered Jan 10 '12 at 20:23

Joop Eggen

107,315
7
83
138

A constant interface (or abstract class) is generally considered as an anti-pattern. Static imports have been introduced to be able to have the same advantages without the antipattern. Your remark about imports makes no sense at all. Imports are only used at compile time. They aren't in the class file. Whether you import or not, a constant is always inlined. – JB Nizet Jan 10 '12 at 20:29
@JBNizet yes **interface** is an anti-pattern, therefore _"though hiding the origin."_ On **imports**: imported class names appear normally in the constant pool of a compiled class; not so for the above case. But agreed, I would call that a compiler specific bug. – Joop Eggen Jan 10 '12 at 20:41

How to implement Constants in Java

5 Answers5