Handling Null Values in Java: Empty Collections, Optional, and Null‑Object Pattern

In many Java projects developers frequently write scattered null checks that lead to confusing code and potential NullPointerExceptions; this article collects several techniques to handle null values more safely and readably.

Business‑level null values

Consider a UserSearchService interface with methods List<User> listUser() and User get(Integer id) . When testing with TDD we discover two questions: should listUser() return null or an empty list when no data exists, and should get() throw an exception or return null when the user is missing.

Empty collection return

Returning null for a collection forces callers to perform null checks, increasing the risk of NullPointerExceptions. A safer implementation returns an empty list using Guava’s Lists.newArrayList() :

public List<User> listUser() {
    List<User> userList = userListRepository.selectByExample(new UserExample());
    if (CollectionUtils.isEmpty(userList)) {
        return Lists.newArrayList(); // return empty collection
    }
    return userList;
}

Now callers can rely on receiving a non‑null list.

Documenting possible null returns

For methods that may legitimately return null , add Javadoc with @exception or use JSR‑303/JSR‑305 annotations to make the contract explicit:

/**
 * Get user by id.
 * @param id user id
 * @return user entity
 * @exception UserNotFoundException if the user does not exist
 */
User get(Integer id);

Alternatively, expose the possibility of an absent value via Optional<User> :

/**
 * Get user by id, may be absent.
 */
Optional<User> getOptional(Integer id);

Null‑Object pattern

When converting a domain object to a DTO, a null source object often forces the DTO fields to be set to empty strings. Instead, create a special subclass (e.g., NullPerson ) that returns default values:

static class NullPerson extends Person {
    @Override
    public String getAge() { return ""; }
    @Override
    public String getName() { return ""; }
}

Then the conversion code becomes straightforward:

Person person = getPerson(); // may return new NullPerson()
personDTO.setDtoAge(person.getAge());
personDTO.setDtoName(person.getName());

Using Optional correctly

Optional is ideal for representing “value may be present” in return types, but should not be used for method parameters or to wrap collections. For example, a method List listUser(Optional username) creates ambiguity; instead provide two overloads: one with a String parameter and one without.

When handling an Optional variable, avoid calling get() directly; use ifPresent , orElse , or orElseThrow to preserve its intent.

Guidelines summary

Return empty collections instead of null when a collection may be empty.

Use Optional<T> for single‑object return values that can be absent.

Do not wrap collections in Optional .

Do not use Optional as a method parameter.

Document nullability with JSR‑303 ( @NotNull ) or JSR‑305 ( @Nullable , @CheckForNull ) annotations.

Avoid abusing Optional in bean getters; keep getters simple and document expected nullability.

By applying these practices, code becomes more robust, easier to read, and less prone to NullPointerExceptions.