Question

What's Java's main convention for storing a predefined set of strings? Right now I have a class that contains all of the strings that I use, but it feels like there's definietly a better way to do this.

This is what I'm doing within a my_strings.java class

public final static String s1 = "test";
public final static String s2 = "test2";
...
Was it helpful?

Solution

You can use resource bundles. Create a file called messages.properties in src or the subdirectory corresponding to the desired package and add strings to it in the following manner. No quoting is needed.

ClassThatUsesAString.stringName=foo
AnotherClass.stringName=bar
AnotherClass.anotherString=baz

You can then access these strings as follows:

ResourceBundle rsrc = ResourceBundle.getBundle("messages");

and then:

rsrc.getString(stringName);

For example, if FooClass requires string quxString, then add to messages.properties:

FooClass.quxString=waldo was here

Notice lack of quotes. Now grab it with:

rsrc.getString("FooClass.quxString");

This does not enforce class boundaries and naming with the class is only for convenience.

If the strings are related closely, an enum may be better, either directly, or specifying message names for different localizations(i.e. an enum contains "ECONNREFUSED" and "ECONNABORTED" and those map to "Connection refused" and "Connection aborted" in one bundle and "conexión rechazada"/"Conexión abortada" in another bundle

Eclipse users: Eclipse does this automagically (though in a more complex fashion) with Source→Externalize Strings

OTHER TIPS

There are two ways. If they are related, or they specify a concept, you can use an enum. Otherwise, the way to go is to use ResourceBundle with .properties file. I would also give these strings sensible names instead of s1, or s2.

static final variables are actually Constants by definition, because their values remain constant and can not be changed thereafter.

I assume your my_strings.java is a concrete class and not an interface - why interface is a bad idea? read Joshua Bloch on Constant Interface Anti-Pattern

The recommended approach is to determine the context of the constant by looking at which classes use those constants?

  1. If a constant is used by a single class - put the constant in that particular class and make it private.

  2. If a constant is used by more than one classes of but they all are inherited from one another in a hierarchical fashion, then put the constant in the top most class up in the hierarchy and make it protected. So, it will remain accessible to all child classes.

  3. If a constant is used by more than one classes and all of them are not linked via inheritance hierarchy, but belongs to same package, then put the constant in a class that is most relevant from a domain perspective and make it package-private (no access modifier)

  4. If a constant is used by more than one classes and all of them are not linked via inheritance hierarchy and belongs to multiple packages, then put the constant in a class that is most relevant from a domain perspective and make it public.

In the end, some generic useful coding conventions:

  1. Use camel case for class names, like: MyStrings.java

  2. Use upper case for constants and to separate two words use underscore '_', like: DEFAULT_VALUE

You can use a .properties file with your Strings. That way you may handle different languages, changing the reference to the file.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top