Utility Classes

Introduction

A utility class (or Util class) in Java is a class that contains public static methods of "common interest" and are a mean of code reuse and code structuring. I.e. the methods are intended to be used at multiple places in an application or even cross multiple applications (even if they are "currently" called just once).

Typically, a utility class groups methods that are related to the same topic. Ideally, the name of the class reflects this topic.

Utility Class Skeleton

The skeleton of a utility class may look like this:

package my.company.projectname;
...
import org.abego.commons.lang.exception.MustNotInstantiateException;

public final class <<Topic>>Util {

    <<Topic>>Util() {
        throw new MustNotInstantiateException();
    }
    ...
}

The class is final because utility classes must not be extended.

A utility class is a container for public static methods and not intended to be instantiated. Therefore the constructor is not public.

private vs. package-private Constructor

The easiest way to disable instance creation of a class is to make the class's default constructor private.

However, code coverage tools may report the private constructor as uncovered code.

To workaround this problem create a package-private constructor instead of the private one and call that constructor from a test method, i.e. create an instance of the utility class. To make this work your test class must belong to the same package as your utility class. This is a well known practice to give your test code access to non-public parts of the class under test.

As we still don't want allow instances of the utility class we throw an exception in the constructor, i.e. the constructor will never create instances. Throwing the exception is also useful when writing the test method for the constructor: as a proper test method must have an assertion we can now add the assertion that the constructor throws a (well defined) exception.

So the test code may look like this

package my.company.projectname;
...
import org.abego.commons.lang.exception.MustNotInstantiateException;
import static org.junit.jupiter.api.Assertions.assertThrows;

class <<Topic>>UtilTest {
    @Test
    void constructor() {
        assertThrows(MustNotInstantiateException.class, <<Topic>>Util::new);
    }
    ...
}

(Notice: the package-private test code trick does not work when using Java modules (Java 9+) and putting main and test code in two different modules, because with Java modules "slip packages" (using the same package in two modules) is not allowed.)

Naming Utility Classes

The name of a utility class should reflect the topic its methods are dealing with. In addition the name should tell the class is a utility class. There are some commonly used ways to achieve this.

<<Topic>>Util or <<Topic>>Utils

Create a utility class by appending Util or Utils to the name of the topic the utility class is about.

E.g. when the utility class provides method to simplify working with File objects the utility class would be named FileUtil or FileUtils.

<<Topic>>s

Create a utility class by appending s to the name of the topic the utility class is about, especially when the topic name is a type name.

E.g. when the utility class provides method to simplify working with arrays the utility class would be named Arrays.

Examples from the Java runtime that use this naming scheme are java.util.Arrays or java.util.Collections.

However, the trailing s may also be interpreted as a plural name and mislead the reader to think of the class as some kind of collection. E.g. Files may mean "multiple File objects" or "the utility class for the File topic". Especially when working with business domain classes introducing "plural" types beside the singular class is a common practices. Think of Account and Accounts. Because of this using the s suffix is not a reliable way to tell that a class is a utility class.

Util, Utils or Utilities

One may name a utility class Util, Utils or Utilities. In that case you may be able to tell the topic of the class by looking at the context of the class, like the package it belongs to.

Sometimes, especially in smaller code bases, the names Util, Utils or Utilities are also used for utility classes that have a very general topic like "All utility methods of this application...".

Other Names

Following a fixed naming convention is not required for a class to be a utility class. Sometimes you will find classes that are utility classes but you cannot tell that by their name.

An example from the Java runtime of a utility class with a "free name" is java.lang.Math.

The "Utility Class" Ambiguity

Notice there is not just one definition for "utility class". The term "utility class" may also be used with other meanings. E.g. the class documentation for the JRE class java.beans.PropertyChangeSupport starts with:

This is a utility class that can be used by beans that support bound properties. ...

However, according to "our" definition the class PropertyChangeSupport is not a utility class. Some people would call PropertyChangeSupport a "Helper class".

Reading Tips

• Java Utility Classes (in Baeldung "Java Helper vs. Utility Classes")