Social Media

Why do we still create Util classes?

Its been niggling at me for a while, a few years even, but why do we insist on creating our own util classes like StringUtil’s, DateUtil’s or CollectionUtil’s when we have great open source projects that contain these classes and methods? In fact recently I foolishly created a CSVUtil class instead of using apache commons csv or opencsv

The most common method you see is a StringUtil.isNullOrEmpty. It will be similar to –

Its not bad code, and keeps you DRY (Dont Repeat Yourself) from repeated null or empty string checks.

But the problem is –

  • Reinventing the wheel because there are a lot of great libraries providing this util and more
  • Created an artifact that you need to support, write unit tests
  • Impact on code coverage – if you dont unit test then you get a black mark against your code coverage
  • Chance you have introduced a bug

One reason we see code like this is they are an organisational software legacy, where in the pre-Java8 world we checked for null as we didnt have Optional classes.

What to use instead?

  • Apache Commons – In my experience this is the most common set of utilities, and probably closely match the util they would replace
  • Google Guava – These are newer than Apache Commons, although are now well established. The approach is slightly different and allow you to method chain. This might suit your coding style better

Selection

The choice of library isnt as important as consistency – so try not to mix apache commons in one part of the code, with the guava implementation in another part of the code. This will make future maitenance easier

Caveat

As with all the best rules there are times when you need to break them. I would create a util class when –

  • Specific Implementation – Package I’m using doesnt contain the method I need, but I would try to use the existing util as the basis for this
  • pre-Java8 – I might create a util as a facade on say Date’s or because I dont have Optional
  • Procrastination – The final reason for creating the util is to procrastinate, and avoid my main task! I create the util then at least I can feel productive at my next standup 🙂

So my New Years resolution for 2017 is to stop creating these classes and use tried and tested utils, and try and replace them when I see them!

 

About the Author Martin Farrell

My name is Martin Farrell. I have almost 20 years Java experience. I specialize inthe Spring Framework and JEE. I’ve consulted to a range of businesses, and have provide Java and Spring mentoring and training.

You can learn more at About

follow me on:

Leave a Comment:

3 comments
Caleb Cushing says 15/12/2016

My thoughts on why I still make them, and the ones I use most commonly. Spring’s Utils in core and other modules, Guava, Apache Commons Lang 3. The most common reason I write my own Utils is because the existing Util classes don’t have the API I want.

1. Spring
Pro’s: Spring Utils are great, throw runtime exceptions, and seem to have what I need
Con’s: requires that I put spring-core as a compile time dependency
Fixes: Pray that Juergen will take my suggestion of making Spring Utils it’s own Jar
2. Guava
Pro’s: Lot’s of useful classes and utilities not in core. In a post Java 8 world this is the best for making your own collections or using Certain Builders to help you do things.
Con’s: Lot’s of formerly useful classes that are better served by features added to Java 7/8, no support for the interfaces added in 8 where there’s overlap. Also preventing dev’s from using pieces you don’t want anymore.
Fixes: Start removing code that’s really only useful in old versions, and split that into its own jar.
3. Apache Commons Lang 3
Pro’s: Lot’s of useful utility methods, imho, less useful classes for extension.
Con’s: checked exceptions that make these methods almost as annoying as the ones in Java core. :/
Fixes: No one wants to deal with checked exceptions when doing reflection Apache!

Fixes: In many of these cases the needs are so freaking common that they need to be added to Java core. 9/10 Java users probably agree Java needs a new reflection API and some convenience methods these API’s add. At least some of them were actually added in 7 and 8.

Reply
Vojtech Ruzicka says 09/08/2017

Nice Article. However, in my opinion – using util classes have several significant disadvantages such as difficult testing, tight coupling or proxying problems (see my post for detailed explnation: http://vojtechruzicka.com/avoid-utility-classes/). So when there is a case you don’t find required logic in an existing third party util class, it would be actually be better not to create your own util class at all and rather choose a regular class for that.

Reply
When a blank isnt blank - javabullets says 15/09/2017

[…] Entity Lifecycle Why do we still create Util classes? Introduction to Spring Data REST @Named vs @ManagedBean How […]

Reply
Add Your Reply