Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Why Do We Still Create Util Classes?

DZone's Guide to

Why Do We Still Create Util Classes?

Utils can be handy, but they're largely unnecessary. Stick with Apache Commons or Guava and only create utils when you really need to.

· Java Zone
Free Resource

What every Java engineer should know about microservices: Reactive Microservices Architecture.  Brought to you in partnership with Lightbend.

It's been niggling at me for a while, a few years even, but why do we insist on creating our own util classes like StringUtils, DateUtils, or CollectionUtils 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 this:

public static boolean isNullOrEmpty(String myString) {
  if (myString == null || "".equals(myString)) {
    return true;    
  } else {
    return false;    
  } 
}


It's not bad code, and it keeps you DRY (Don't Repeat Yourself) from repeated null or empty string checks.

But there are some problems:

  • Reinventing the wheel because there are a lot of great libraries providing this util and more.
  • Created an artifact that you need to support and write unit tests for.
  • Impact on code coverage – if you don't 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 that they are an organizational software legacy, whereas, in the pre-Java8 world, we checked for null — we didn't have Optional classes.

What to Use Instead?

  • Apache Commons: In my experience, this is the most common set of utilities, and they 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 isn't 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 maintenance 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: The package I’m using doesn't 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 don't 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 Year's resolution for 2017 is to stop creating these classes and use tried and tested utils, and try and replace them when I see them!

Microservices for Java, explained. Revitalize your legacy systems (and your career) with Reactive Microservices Architecture, a free O'Reilly book. Brought to you in partnership with Lightbend.

Topics:
java ,apache commons ,guava ,utilities

Published at DZone with permission of Martin Farrell, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

THE DZONE NEWSLETTER

Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

X

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}