DZone
Java Zone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
  • Refcardz
  • Trend Reports
  • Webinars
  • Zones
  • |
    • Agile
    • AI
    • Big Data
    • Cloud
    • Database
    • DevOps
    • Integration
    • IoT
    • Java
    • Microservices
    • Open Source
    • Performance
    • Security
    • Web Dev
DZone > Java Zone > Why Do We Still Create Util Classes?

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.

Martin Farrell user avatar by
Martin Farrell
·
Dec. 14, 16 · Java Zone · Opinion
Like (29)
Save
Tweet
26.86K Views

Join the DZone community and get the full member experience.

Join For Free

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!

unit test Open source Reinventing the wheel Code coverage Google Guava IT Implementation Library Strings

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

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • 8 Must-Have Project Reports You Can Use Today
  • DZone's Article Submission Guidelines
  • Cross-Functional Team Management
  • API Security Tools: What To Look For

Comments

Java Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • MVB Program
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends:

DZone.com is powered by 

AnswerHub logo