Why is there no String.Empty in Java? [closed]

Question

String.EMPTY is 12 characters, and "" is two, and they would both be referencing exactly the same instance in memory at runtime. I'm not entirely sure why String.EMPTY would save on compile time, in fact I think it would be the latter.

Especially considering Strings are immutable, it's not like you can first get an empty String, and perform some operations on it - best to use a StringBuilder (or StringBuffer if you want to be thread-safe) and turn that into a String.

Update
From your comment to the question:

What inspired this is actually TextBox.setText("");

I believe it would be totally legitimate to provide a constant in your appropriate class:

private static final String EMPTY_STRING = "";

And then reference it as in your code as

TextBox.setText(EMPTY_STRING);

As this way at least you are explicit that you want an empty String, rather than you forgot to fill in the String in your IDE or something similar.

Use org.apache.commons.lang.StringUtils.EMPTY

If you want to compare with empty string without worrying about null values you can do the following.

if ("".equals(text))

Ultimately you should do what what you believe is clearest. Most programmers assume "" means empty string, not a string someone forgot to put anything into.

If you think there is a performance advantage, you should test it. If you don't think its worth testing for yourself, its a good indication it really isn't worth it.

It sounds like to you try to solve a problem which was solved when the language was designed more than 15 years ago.

Don't just say "memory pool of strings is reused in the literal form, case closed". What compilers do under the hood is not the point here. The question is reasonable, specially given the number of up-votes it received.

It's about the symmetry, without it APIs are harder to use for humans. Early Java SDKs notoriously ignored the rule and now it's kind of too late. Here are a few examples on top of my head, feel free to chip in your "favorite" example:

• BigDecimal.ZERO, but no AbstractCollection.EMPTY, String.EMPTY
• Array.length but List.size()
• List.add(), Set.add() but Map.put(), ByteBuffer.put() and let's not forget StringBuilder.append(), Stack.push()

Apache StringUtils addresses this problem too.

Failings of the other options:

• isEmpty() - not null safe. If the string is null, throws an NPE
• length() == 0 - again not null safe. Also does not take into account whitespace strings.
• Comparison to EMPTY constant - May not be null safe. Whitespace problem

Granted StringUtils is another library to drag around, but it works very well and saves loads of time and hassle checking for nulls or gracefully handling NPEs.

If you really want a String.EMPTY constant, you can create an utility static final class named "Constants" (for example) in your project. This class will maintain your constants, including the empty String...

In the same idea, you can create ZERO, ONE int constants... that don't exist in the Integer class, but like I commented, it would be a pain to write and to read :

for(int i=Constants.ZERO; ...) {
    if(myArray.length > Constants.ONE) {
        System.out.println("More than one element");
    }
}

Etc.

All those "" literals are the same object. Why make all that extra complexity? It's just longer to type and less clear (the cost to the compiler is minimal). Since Java's strings are immutable objects, there's never any need at all to distinguish between them except possibly as an efficiency thing, but with the empty string literal that's not a big deal.

If you really want an EmptyString constant, make it yourself. But all it will do is encourage even more verbose code; there will never be any benefit to doing so.