Is StringUtils.EMPTY recommended?

JavaStringApache Commons

Java Problem Overview


Do you use StringUtils.EMPTY instead of ""?

I mean either as a return value or if you set a the value of a String variable. I don't mean for comparison, because there we use StringUtils.isEmpty()

Java Solutions


Solution 1 - Java

Of course not. Do you really think "" is not clear enough ?

Constants have essentially 3 use cases:

  1. Document the meaning of a value (with constant name + javadoc)
  2. Synchronize clients on a common value.
  3. Provide a shortcut to a special value to avoid some init costs

None apply here.

Solution 2 - Java

I use StringUtils.EMPTY, for hiding the literal and also to express that return StringUtils.EMPTY was fully expected and there should return an empty string, "" can lead to the assumption that "" can be easily changed into something else and that this was maybe only a mistake. I think the EMPTY is more expressive.

Solution 3 - Java

No, just use "".

The literal "" is clear as crystal. There is no misunderstanding as to what was meant. I wouldn't know why you would need a class constant for that. I can only assume that this constant is used throughout the package containing StringUtils instead of "". That doesn't mean you should use it, though.

If there's a rock on the sidewalk, you don't have to throw it.

Solution 4 - Java

I'm amazed at how many people are happy to blindly assume that "" is indeed an empty string, and doesn't (accidentally?) contain any of Unicode's wonderful invisible and non-spacing characters. For the love of all that is good and decent, use EMPTY whenever you can.

Solution 5 - Java

I will add my two cents here because I don't see anybody talking about String interning and Class initialization:

  • All String literals in Java sources are interned, making any "" and StringUtils.EMPTY the same object
  • Using StringUtils.EMPTY can initialize StringUtils class, as it accesses its static member EMPTY only if it is not declared final (the JLS is specific on that point). However, org.apache.commons.lang3.StringUtils.EMPTY is final, so it won't initialize the class.

See a related answer on String interning and on Class initialization, referring to the JLS 12.4.1.

Solution 6 - Java

I don't really like to use it, as return ""; is shorter than return StringUtils.EMPTY.

However, one false advantage of using it is that if you type return " "; instead of return "";, you may encounter different behavior (regarding if you test correctly an empty String or not).

Solution 7 - Java

If your class doesn't use anything else from commons then it'd be a pity to have this dependency just for this magic value.

The designer of the StringUtils makes heavy use of this constant, and it's the right thing to do, but that doesn't mean that you should use it as well.

Solution 8 - Java

No, because I have more to write. And an empty String is plattform independent empty (in Java).

File.separator is better than "/" or "\".

But do as you like. You can't get an typo like return " ";

Solution 9 - Java

I find StringUtils.EMPTY useful in some cases for legibility. Particularly with:

  1. Ternary operator eg.

     item.getId() != null ? item.getId() : StringUtils.EMPTY;
    
  2. Returning empty String from a method, to confirm that yes I really wanted to do that.

Also by using a constant, a reference to StringUtils.EMPTY is created. Otherwise if you try to instantiate the String literal "" each time the JVM will have to check if it exists in the String pool already (which it likely will, so no extra instance creation overhead). Surely using StringUtils.EMPTY avoids the need to check the String pool?

Solution 10 - Java

Honestly, I don't see much use of either. If you want to compare egainst an empty string, just use StringUtils.isNotEmpty(..)

Solution 11 - Java

I am recommending to use this constant as one of the building stones of a robust code, to lower the risk of accidently have nonvisible characters sneak in when assigning an empty string to a variable.

If you have people from all around the world in your team and maybe some of them not so experienced, then it might be a good idea to insist on using this constant in the code.

There are lots of different languages around and people are using their own local alphabet settings on their computers. Sometimes they just forget to switch back when coding and after they switch and delete with backspace, then text editor can leave some junk inside of "". Using StringUtils.EMPTY just eliminate that risk.

However, this does not have any significant impact on the performance of the code, nor on the code readability. Also it does not resolve some fundamental problem you might experience, so it is totally up to your good judgement weather you will use this constant or not.

Solution 12 - Java

Yes, it makes sense. It might not be the only way to go but I can see very little in the way of saying this "doesn't make sense".

In my opinion:

  • It stands out more than "".
  • It explains that you meant empty, and that blank will likely not do.
  • It will still require changing everywhere if you don't define your own variable and use it in multiple places.
  • If you don't allow free string literals in code then this helps.

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
QuestionkeuleJView Question on Stackoverflow
Solution 1 - JavaDavid PierreView Answer on Stackoverflow
Solution 2 - JavaChristopher KlewesView Answer on Stackoverflow
Solution 3 - JavaErick RobertsonView Answer on Stackoverflow
Solution 4 - Javaj__mView Answer on Stackoverflow
Solution 5 - JavaMatthieuView Answer on Stackoverflow
Solution 6 - JavaRomain LinsolasView Answer on Stackoverflow
Solution 7 - JavacherouvimView Answer on Stackoverflow
Solution 8 - JavaChristian KuetbachView Answer on Stackoverflow
Solution 9 - JavaTomView Answer on Stackoverflow
Solution 10 - JavaBozhoView Answer on Stackoverflow
Solution 11 - JavaSašaView Answer on Stackoverflow
Solution 12 - JavaOronView Answer on Stackoverflow