Is making an empty string constant worth it?

Question

I have a cow-orker that swears by

//in a singleton "Constants" class
public static final String EMPTY_STRING = "";

in a constants class available throughout the project. That way, we can write something like

if (Constants.EMPTY_STRING.equals(otherString)) {
    ...
}

instead of

if ("".equals(otherString)) {
    ...
}

I say it's

1. not worth it--it doesn't save any space in the heap/stack/string pool,
2. ugly, and
3. an abuse of a constants class.

Who is the idiot here?

Answer 1

I much prefer seeing EMPTY_STRING.

It makes it english. "".equals 'reads' differently than EMPTY_STRING.equals.

Answer 2

1. yes--it offers no benefit.
2. depends on what you're used to, I'm sure.
3. No, it's just a constant--not an abuse.

Answer 3

I don't like either choice. Why not if (otherString.length() == 0)

Edit: I actually always code

if (otherString == null || otherString.length() == 0)

Answer 4

String literals are interned by default, so no matter how many times you refer to "" in code, there will only be one empty String object. I don't see any benefit in declaring EMPTY_STRING. Otherwise, you might as well declare ONE, TWO, THREE, FOUR, etc. for integer literals.

Of course, if you want to change the value of EMPTY_STRING later, it's handy to have it in one place ;)

Answer 5

Why on earth would you want a global variable in Java? James Gosling really tried to get rid of them; don't bring them back, please.

Either

0 == possiblyEmptyString.length()

or

possiblyEmptyString.isEmpty() // Java 6 only

are just as clear.

Answer 6

Your co-worker is right!

What if they change the definition of an EMPTY_STRING to be "Supercalifragilisticexpialidocious"? YOU are going to look pretty silly having to go through all your source code changing those "".equals() by hand!

He'll be able to change it in one place!

</sarcasm>

Answer 7

Ironically the whole point of constants is to make them easily changeable. So unless your co-worker plans to redefine EMPTY_STRING to be something other than an empty string - which would be a really stupid thing to do - casting a genuine fixed construct such as "" to a constant is a bad thing.

As Dan Dyer says, its like defining the constant ONE to be 1: it is completely pointless and would be utterly confusing - potentially risky - if someone redefined it.

Answer 8

The same argument comes up in .NET from time to time (where there's already a readonly static field string.Empty). It's a matter of taste - but personally I find "" less obtrusive.

Answer 9

Hmm, the rules are right but are being taken in a different sense! Lets look at the cause, firstly all object references in java are checked by equals(). Earlier on, in some languages it was done using '==' operator, if by accident someone used '=' for '==', a catastrophe. Now the question of magic numbers/constants, for a computer all constants/numbers are similar. Instead of 'int ONE=1' one can surely use 1, but will that hold true for double PI = 3.141...? What happens if someone tries to change the precision sometime later.

If we were to come up with a check list, what would the rule be address the general guideline isn't it? All I mean to say is that rules are supposed to aid, we can surely bend the rules only when we know them very well. Common sense prevails. As suggested by a friend of mine, program constants like 0/1 which denote exit conditions can be hard coded and hence magic number principle doesn't apply. But for those which participate in logical checks/rules, better keep them as configurable constants.

Answer 10

We just just the following for situations like this

public class StaticUtils
{
    public static boolean empty(CharSequence cs)
    {
        return cs == null || cs.length() == 0;
    }

    public static boolean has(CharSequence cs)
    {
        return !empty(cs);
    }
}

Then just import static StatiUtils.*

Answer 11

I'm with your coworker. While the empty string is hard to mistype, you can accidentally put a space in there and it may be difficult to notice when scanning the code. More to the point it is a good practice to do this with all of your string constants that get used in more than one place -- although, I tend to do this at the class level rather than as global constants.

FWIW, C# has a static property string.Empty for just this purpose and I find that it improves the readability of the code immensely.

Answer 12

One case where it does make sense to have a constant with value of empty string is when you the name captures the semantics of the value. For example:

if (Constants.FORM_FIELD_NOT_SET.equals(form.getField("foobar"))) {
    ...
}

This makes the code more self documenting (apart from the argument that a better design is to add the method checking whether a field is set to the form itself).

Answer 13

Hehe, funny thing is: Once it compiles, you wont see a difference (in the byte-code) between the "static final" thing and the string literal, as the Java-compiler always inlines "static final String" into the target class. Just change your empty string into something recognizable (like the LGPL-text) and look at the resulting *.class file of code that refernces that constant. You will find your text copied into that class-file.

Answer 14

As a tangent to the question, I generally recommend using a utility function when what you're really checking for is "no useful value" rather than, specifically, the empty string. In general, I tend to use:

import org.apache.commons.lang.StringUtils;

// Check if a String is whitespace, empty ("") or null.
StringUtils.isBlank(mystr); 
// Check if a String is empty ("") or null.
StringUtils.isEmpty(mystr);

The concept being that the above two:

• Check the various other cases, including being null safe, and (more importantly)
• Conveys what you are trying to test, rather than how to test it.