Get rid of your StringUtils!

Get rid of your StringUtils!


Image via CC from Alexei Kuznetsov

Probably every Java developer has developed at least one String utility class in his life.
Need a proof? Feed “java StringUtil” to your favorite search engine – I found 20 different implementations among the first 30 search hits only!

There is a simple reason for that – Strings are used quite frequently in common Java programs (especially when UI is involved), and the java.lang.String class itself offers only a very limited API for String operations.

Since almost everybody needs String utilities and the JDK does not provide them, there are plenty of third-party open source libraries filling the gap with their own implementations. So why are people not using them and writing their own utilities instead? I suspect the do-it-yourself approach is very tempting since the problems in this domain are usually easy to understand, the solution code is mostly short and not too hard to implement. Writing a two-liner yourself seems to be faster than digging through JavaDoc or code of third-party libraries to find a method solving your String problem.

But this is deceiving – even a two-liner can contain plenty of bugs, needs to be tested and maintained.

Here are some proven and commonly used open source String utility implementations:

The leader of the pack – Apache Commons

Apache Commons has been around for more than 10 years now. Its language component offers several utility classes with null-safe methods for String parsing and manipulation. Also more powerful versions of StringTokenizer and StringBuilder can be found. Check out the packages org.apache.commons.lang3 and org.apache.commons.lang3.text for details.

Make sure you use version 3 which supports Java 5 language features like generics.

The contender – Google Guava

Google Guava version was first released in 2009 and has delevoped into a serious alternative or complement to Apache Commons since then. It supported Java generics from the beginning and has a more modern API than Commons.

Google Guava has powerful tools for joining and splitting Strings, character matching and word handling. See the JavaDoc of package or look at the excellent Wiki page about Strings.

The alternative – Spring framework

If you’re a Spring addict, the Spring framework will be part of your project anyway. Then you can as well use org.springframework.util.StringUtils which offers 40+ static methods for String parsing and manipulation.


There are many good reasons to use String utilities from third-party libraries:

  • They’ve been tested well
  • They’ve been used successfully in hundreds of projects
  • They’re mostly bug-free

Unless you have been infected with the NIH syndrome, or work in a project with severe restrictions on which libraries to use, there is no good argument for implementing String utilities yourself. So go ahead and clean up your code!

  • Kevin Peck
    Posted at 2:55 pm, November 6, 2013

    There are times when you want as small as possible executable. Looking at Guava the jar file is 2.2 meg. Not something I want to pop into every Android project. It would be nice if there was a source file set and a JAR builder to extract and create a JAR of just what you need.

    I do agree that overuse of StringUtil, ColorUtil. FileUtil, IOUtil, etc. is happening daily. If the compiler could toss the stuff you don’t need…. But reflection and all sorts of other things get in the way making that a potential mess.

    We do use Apache commons in our large server project. I have used it in large desktop projects too. I don’t use it in smaller one off utility programs or my small Android projects because I just don’t want the baggage. For those I end up copying in just the static methods I need. Not an optimal solution and if I find and fix a bug I forget to fix it in my base code set from time to time.

  • Alexey Ragozin
    Posted at 5:04 pm, November 6, 2013

    All three libraries you have mentioned are toxic dependncies (i.e. version confilcts in complex projects). Adding them as dependencies just for sake of couple of two line helper methods – very bad idea IMHO.

    Two lines of code have zero maintenance cost.

    Migrating to newer version of Spring just because one of your dependencies require newer version so sake of some helper – this is real maintenance pain (and hours wasted for nothing).

  • Maurizio
    Posted at 9:39 pm, November 6, 2013

    @Alexey I think that the author didn’t mean to introduce Spring dependencies just for the SU class.

    For what concerns the commons lang, it has no external dependences and is pretty much conflictless: the different versions can live together without any problem.

  • David
    Posted at 10:07 pm, November 6, 2013

    @Alexey Ragozin Nonsense – Guava and Commons are self contained so if you have version conflicts its because your ‘complex’ project is probably a mess. Fix you own code before putting down well tested code.

  • Yann Cébron
    Posted at 8:30 am, November 7, 2013

    Most often, (over)use of String and other “primitive” data types shows a lack of OO modelling. I much prefer creating dedicated classes wrapping such data with associated behaviour instead of moving around a bunch of Strings through various “*Utils” classes. Yes, it might look like creating too many classes, but in the long term your system becomes much more semantic and thus easier to maintain. See also

  • Posted at 8:37 am, November 7, 2013

    this is were OSGi comes to the rescue 🙂

  • Daniel Keck
    Posted at 12:59 pm, November 8, 2013

    Java is THE programming language (thought in schools and universities; more and more devices – though no native silicon Java processor is inside – are able to execute bytecode). The wide range for solutions in this field is probably a result of the millions of “Java developers” coming from areas hardly connected to (OO) programming but with the requirement of data processing.

    I think to know many open APIs is a cost-effective way of programming because you can delegate your work for free to someone else but you must first learn and evaluate these APIs and this can become a real waste of time. Concerning beauty (not taking money and time into account) I am convinced Y. Cébrons approach is the one to take but only few will build a city while actually needing a house.

  • p
    Posted at 11:06 pm, November 30, 2013

    I wouldn’t use guava joiner, or any of the other contenders.
    – They let you join together strings that might contain the separator. You cannot always recover the original items by splitting the result. Test failed. You needed to be told to use a proper csv generator with quoting and escaping, or to provide an explicit waiver. If you are sure that it cannot happen or does not matter then explain why. Otherwise you can quote it, or validate and throw an exception.
    – They allocate a default StringBuilder that will be too small and need extending.
    – You have to choose a version and add a large extra jarfile to your project.
    – You already have AbstractCollections.toString and Arrays.toString. Maybe one of them will do the job. If not, then take a look at their source. You can copy it and adapt it: at least specify an initial StringBuilder capacity.

Post a Comment