Ray’s Law of String Util Reinvention: “The probability of somebody creating a ‘Util’ class that contains common String manipulation methods is directly proportional to the number of people working on a project. When we have more than 3 developers, this probability is 100%.”
We’ve all been there haven’t we? After checking whether a String is blank one too many times, we decide to put this into a method and call it some unimaginative name, the most common of which is isEmpty. The most delightful occasion is when there are about 10 people working in the same project, and we have more than one StringUtils scattered in different packages doing roughly the same thing. Or one is StringUtil and the other is CommonUtil, but both have slightly different String manipulation methods.
Really, one shouldn’t anymore. Whenever you need something not included in JDK’s java.lang.String, your default action should be to go this existing, tested StringUtils implementation and check it out to see if it fits your needs. I’ve found that most of the time it does, unless the String manipulation is very domain/application-specific.