Get rid of your StringUtils!

5480421664 b545d6083c n 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 com.google.common.base 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.

Conclusion

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!

You may also like...

Share this Post

Twitter8
Google+1
LinkedIn
Facebook

Tags

9 Responses to “Get rid of your StringUtils!”

  1. Kevin Peck says:

    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.

  2. Hi Kevin,

    you have a point here. If application size matters, it is indeed questionable whether it is worth to have an extra 2.2M (or 320K with Apache Commons) only to be able to reuse a bunch of methods of one single class.

    However I have always considered embedded development as completely different from traditional software development. Some best practices for the latter are just not applicable to the embedded space due to memory / disk space / performance constraints. In my last embedded project, we had to reduce object instantiations because of performance issues – it was the right thing to do, but the resulting code was terrible to read and maintain! So I still think getting rid of your own String utilities should in any case be the ultimate goal, but there can always be circumstances where it cannot be reached.

  3. Alexey Ragozin says:

    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).

  4. Maurizio says:

    @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.

  5. David says:

    @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.

  6. Yann Cébron says:

    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 http://www.markhneedham.com/blog/2008/11/06/object-calisthenics-first-thoughts/

  7. @Alexey,
    this is were OSGi comes to the rescue :)

  8. Daniel Keck says:

    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.

  9. p says:

    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.

9 responses so far

Written by . Published in Categories: EclipseSource News, Editors choice