Sharing constant strings in Java across many classes?

JavaString

Java Problem Overview


I'd like to have Java constant strings at one place and use them across whole project (many classes).

What is the recommended way of achieveing this?

Java Solutions


Solution 1 - Java

public static final String CONSTANT_STRING="CONSTANT_STRING";

constants should be:

  1. public - so that it can be accessed from anywhere
  2. static - no need to create an instance
  3. final - since its constants shouldnt be allowed to change
  4. As per Java naming convention should be capitalized so that easy to read and stands out in Java documentation.

There are instances where interfaces are used just to keep constants, but this is considered a bad practice because interfaces are supposed to define the behavior of a type.

A better approach is to keep it in the class where it makes more sense.

for e.g.

JFrame has EXIT_ON_CLOSE contant, any class which subclasses JFrame will have access to it and it also makes sense to keep in JFrame and not in JComponent as not all components will have an option to be closed.

Solution 2 - Java

As @mprabhat answered before, constants should be public, static, final, and typed in capital letters.

Grouping them in a class helps you:

  1. Don't need to know all the constants you have. Many IDEs (like Eclipse) show you the list of all the fields a class has. So you only press CTRL+SPACE and get a clue of which constants you can use.

  2. Making them typesafe at compile time. If you used Strings, you might misspell "DATABASE_EXCEPTION" with "DATABSE_EXSCEPTION", and only notice during execution (if you are lucky and notice it at all). You can also take profit of autocompletion.

  3. Helping you save memory during execution. You'll only need memory for 1 instance of the constant. I.E: (a real example) If you have the String "DATABASE_EXCEPTION" 1000 times in different classes in you code, each one of them will be a different instace in memory.

Some other considerations you might have:

  1. Add javadoc comments, so programmers who use the constants can have more semantic information on the constant. It is showed as a tooltip when you press CTRL+SPACE. I.E:

    /** Indicates an exception during data retrieving, not during connection. */
    public static final String DATABASE_EXCEPTION = "DATABASE_EXCEPTION";
    /** Indicates an exception during the connection to a database. */
    public static final String DATABASE_CONNECTION_EXCEPTION =" DATABASE_CONNECTION_EXCEPTION";
    
  2. Add semantic to the identifier of the constant. If you have the constant "Y", and sometimes means yes and other times year, consider using 2 different constants.

    public static final String Y = "Y"; // Bad
    public static final String YEAR = "Y";
    public static final String YES = "Y"; 
    

It will help you if, in the future, decide to change the values of the constants.

    /** Year symbol, used for date formatters. */
    public static final String YEAR = "A"; // Year is Año, in Spanish.
    public static final String YES = "S"; // Yes is Sí, in Spanish.

3. You might not know the value of your constants until runtime. IE: You can read them from configuration files.

    public class Constants
    {
      /** Message to be shown to the user if there's any SQL query problem. */
      public static final String DATABASE_EXCEPTION_MESSAGE; // Made with the 2 following ones.
      public static final String DATABASE_EXCEPTION = "DATABASE_EXCEPTION";
      public static final String MESSAGE = "MESSAGE";
      
      static {
        DATABASE_EXCEPTION_MESSAGE = DATABASE_EXCEPTION + MESSAGE; // It will be executed only once, during the class's [first] instantiation.
      }

}

  1. If your constants class is too large, or you presume it'll grow too much in the future, you can divide it in different classes for different meanings (again, semantic): ConstantDB, ConstantNetwork, etc.

Drawbacks:

  1. All the members of your team have to use the same class(es), and the same nomenclature for the constants. In a large project it wouldn't be strange to find 2 definitions:

    public static final String DATABASE_EXCEPTION = "DATABASE_EXCEPTION";
    public static final String EXCEPTION_DATABASE = "DATABASE_EXCEPTION"; 
    

separated several hundreds of lines or in different constant classes. Or even worse:

    /** Indicates an exception during data retrieving, not during connection. */
    public static final String DATABASE_EXCEPTION = "DATABASE_EXCEPTION";
    /** Indicates an exception during data retrieving, not during connection. */
    public static final String EXCEPTION_DATABASE = "EXCEPTION_DATABASE"; 

different identifiers, for different values, having the same meaning (and used for the same purposes).

  1. It might make readability worse. Having to write more for doing the same:

    if ("Y".equals(getOptionSelected()) {
    

vs

    if (ConstantsWebForm.YES.equals(getOptionSeleted()) {

3. How should constants be ordered in the class? Alphabetically? All related constants together? In order as they are created/needed? Who sould be responsible of the order being correct? Any (big enough) reordering of constants would be seen as a mess in a versioning system.

Well, it's taken longer than what I expected. Any help/critics is/are welcome.

Solution 3 - Java

You should create a class of the constants that stores all the constants.

like ProjectNameConstants.java

which contains all the constant string static as you can access it through the classname.

e.g.

classname :  MyAppConstants.java

public static final String MY_CONST="my const string val";

you can access it as

MyAppConstants.MY_CONST

Solution 4 - Java

Best practice is to use Java Enum (After Java 5)

Problems with the class approach:

  1. Not typesafe
  2. No namespace
  3. Brittleness

Please check java docs.

public enum Constants {

	CONSTANT_STRING1("CONSTANT_VALUE1"), 
	CONSTANT_STRING2("CONSTANT_VALUE2"), 
	CONSTANT_STRING3("CONSTANT_VALUE3");

	private String constants;

	private Constants(String cons) {
		this.constants = cons;
	}
}

Enums can be used as constants.

Edit: You can call this Constants.CONSTANT_STRING1

Solution 5 - Java

Create a class called Constants at the base of your main package (i.e. com.yourcompany) with all your constants there. Also make the the constructor private so no object will be created from this class:

public class Constants {

	private Constants() {
        // No need to create Constants objects
	}
	
	public static final String CONSTANT_ONE = "VALUE_CONSTANT_ONE";
	public static final String CONSTANT_TWO = "VALUE_CONSTANT_TWO";
}

Solution 6 - Java

public class SomeClass {
    public static final String MY_CONST = "Some Value";
}

If it is supposed to be a pure constants class then make the constructor private as well.

public class Constants {
    public static final String CONST_1 = "Value 1";
    public static final int CONST_2 = 754;

    private Constants() {
    }
}

Then it won't be possible to instantiate this class.

Solution 7 - Java

You should break up your constants into groups they belong, like where they'll be used most, and define them as public static final in those classes. As you go along, it may seem appropriate to have interfaces that define your constants, but resist the urge to create one monolithic interface that holds all constants. It's just not good design.

Solution 8 - Java

I guess the correct answer you're looking for is

import static com.package.YourConstantsClass.*;

Solution 9 - Java

Create a public class and for each constant string create a field like this

public static final String variableName = "string value";

Solution 10 - Java

public enum Constants {

CONSTANT_STRING1("CONSTANT_VALUE1"), 
CONSTANT_STRING2("CONSTANT_VALUE2"), 
CONSTANT_STRING3("CONSTANT_VALUE3");

private String constants;

private Constants(String cons) {
    this.constants = cons;
}
    @JsonValue
@Override
public String toString() {
    return constants;
}

}

Use it Constants.CONSTANT_STRING1.toString()

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
QuestionDanijelView Question on Stackoverflow
Solution 1 - JavamprabhatView Answer on Stackoverflow
Solution 2 - JavaJ.A.I.L.View Answer on Stackoverflow
Solution 3 - JavaHemant MetaliaView Answer on Stackoverflow
Solution 4 - JavaamicnghView Answer on Stackoverflow
Solution 5 - JavaEduardo Sanchez-RosView Answer on Stackoverflow
Solution 6 - JavamabaView Answer on Stackoverflow
Solution 7 - JavaThomView Answer on Stackoverflow
Solution 8 - JavaDineshView Answer on Stackoverflow
Solution 9 - Javauser520288View Answer on Stackoverflow
Solution 10 - JavaNikhil DineshView Answer on Stackoverflow