更进一步，您可以将全局使用的常量放在接口中，这样它们就可以在系统范围内使用。如。

public interface MyGlobalConstants {
    public static final int TIMEOUT_IN_SECS = 25;
}

但是不要执行它。只需在代码中通过完全限定类名直接引用它们。

这完全可以接受，甚至可能是标准。

(public/private) static final TYPE NAME = VALUE;

其中TYPE是类型，NAME是全大写的名称，空格用下划线表示，VALUE是常量值;

我强烈建议不要将常量放在它们自己的类或接口中。

附注:声明为final且为mutable的变量仍然可以更改;但是，变量永远不能指向不同的对象。

例如:

public static final Point ORIGIN = new Point(0,0);

public static void main(String[] args){

    ORIGIN.x = 3;

}

这是合法的，ORIGIN将是(3,0)点。

我使用以下方法:

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() {}
}

例如，我使用Constants.DB.Connection.URL来获取常量。 对我来说，它看起来更“面向对象”。

我更喜欢使用getter而不是常量。这些getter可能返回常量值，例如public int getMaxConnections() {return 10;}，但任何需要常量的东西都将通过getter。

一个好处是，如果您的程序超出了常量的使用范围——您发现它需要可配置——您可以更改getter返回常量的方式。

另一个好处是，为了修改常量，你不必重新编译所有使用它的东西。当引用静态final字段时，该常量的值将被编译到引用它的任何字节码中。

我同意使用界面不是正确的方法。在Bloch的《Effective Java》中，避免这种模式甚至有自己的项目(#18)。

Bloch反对常量接口模式的一个论点是，常量的使用是一个实现细节，但是实现一个使用它们的接口会在导出的API中暴露该实现细节。

public|private static final TYPE NAME = VALUE;模式是一种声明常数的好方法。就我个人而言，我认为最好避免创建一个单独的类来存放所有的常量，但除了个人偏好和风格之外，我还没有看到不这样做的理由。

如果常量可以很好地建模为枚举，请考虑1.5或更高版本中可用的枚举结构。

如果您使用的是1.5以前的版本，您仍然可以通过使用普通的Java类来实现类型安全枚举。(详见这个网站)。

我不会称这个类与常量相同(除了大小写)…我将至少有一类“设置”，或“值”，或“常量”，所有的常量都将存在。如果我有很多，我会将它们分组在逻辑常量类中(UserSettings, AppSettings等)。