Introduction

Sometimes two Java arguments are valid only as a pair. Coordinates, date ranges, and optional credentials often follow the same rule: either both values are present or both are absent. The cleanest code expresses that rule directly instead of burying it inside a long boolean expression.

The Shortest Correct Check

If the invalid case is "exactly one value is null", the direct condition is:

1if ((left == null) != (right == null)) {
2    throw new IllegalArgumentException(
3            "left and right must both be null or both be non-null");
4}

This works because (left == null) and (right == null) are booleans. The != operator is true only when those boolean values differ, which is exactly the mixed null-state case you want to reject.

That makes it more compact than the longer equivalent:

1if (!((left == null && right == null) ||
2      (left != null && right != null))) {
3    throw new IllegalArgumentException("Invalid null combination");
4}

Both versions are correct. The first one is usually easier to read once you know what it means.

Turn the Rule Into a Reusable Helper

If the pattern appears in several constructors or service methods, extract it into a utility:

1public final class Preconditions {
2    private Preconditions() {
3    }
4
5    public static void requireBothOrNeither(
6            Object first,
7            Object second,
8            String firstName,
9            String secondName) {
10        if ((first == null) != (second == null)) {
11            throw new IllegalArgumentException(
12                    firstName + " and " + secondName +
13                    " must either both be null or both be non-null");
14        }
15    }
16}

Usage:

1public final class DateRange {
2    private final Integer startDay;
3    private final Integer endDay;
4
5    public DateRange(Integer startDay, Integer endDay) {
6        Preconditions.requireBothOrNeither(
7                startDay, endDay, "startDay", "endDay");
8        this.startDay = startDay;
9        this.endDay = endDay;
10    }
11}

This keeps domain code focused on the actual concept instead of repeating low-level validation logic.

Do Not Confuse Null-State with Equality

Objects.equals(a, b) answers a different question. It checks whether two values are equal, not whether they share the same null-state.

Example:

1import java.util.Objects;
2
3public class Demo {
4    public static void main(String[] args) {
5        String first = "A";
6        String second = "B";
7
8        System.out.println(Objects.equals(first, second)); // false
9        System.out.println((first == null) == (second == null)); // true
10    }
11}

The pair is valid under the "both present or both absent" rule even though the values are not equal. That is why using equality APIs here often muddies the intent.

Sometimes the Better Fix Is an API Change

Repeatedly validating two nullable parameters is often a design smell. If the values conceptually belong together, wrap them in a single value object:

1public record Coordinates(double latitude, double longitude) {
2}
3
4public class PlaceService {
5    public void save(Coordinates coordinates) {
6        if (coordinates == null) {
7            System.out.println("No coordinates provided");
8            return;
9        }
10
11        System.out.println(coordinates.latitude());
12        System.out.println(coordinates.longitude());
13    }
14}

Now the caller either passes a complete Coordinates object or nothing at all. That avoids the possibility of partial state entirely.

This is often better than passing two boxed types such as Double latitude, Double longitude through multiple layers of code and validating them everywhere.

When a Boolean Is Better Than an Exception

Sometimes you want a predicate instead of a throwing precondition:

1public static boolean haveSameNullState(Object first, Object second) {
2    return (first == null) == (second == null);
3}
4
5public static void main(String[] args) {
6    System.out.println(haveSameNullState(null, null));   // true
7    System.out.println(haveSameNullState("x", "y"));   // true
8    System.out.println(haveSameNullState("x", null));   // false
9}

This works well in validation frameworks where you want to gather several problems and return them together instead of failing on the first mismatch.

Choosing the Most Readable Form

There are two common readable forms:

• invalid case check: (a == null) != (b == null)
• valid case check: (a == null) == (b == null)

Pick the one that matches the control flow. If you want to throw on invalid input, the != form is natural. If you want a reusable boolean predicate that returns true for valid pairs, the == form reads better.

Common Pitfalls

One common mistake is using Objects.equals(a, b) and assuming that covers the null-pair rule. It does not. Equality and null-state are different concepts.

Another mistake is writing the condition in a much longer form than necessary. Validation logic should be easy to scan because it often sits at the edge of important API boundaries.

Developers also sometimes reach for Optional as a parameter type just to express this rule. In most Java code, that makes call sites noisier without improving clarity.

Finally, if the same pair check appears repeatedly, take that as a hint that a dedicated value object may express the domain more cleanly.

Summary

• Use (a == null) != (b == null) to detect the invalid mixed case.
• Use (a == null) == (b == null) when you want a boolean predicate for the valid case.
• Do not confuse value equality with matching null-state.
• Extract the rule into a helper if it appears often.
• Prefer a value object when the two values conceptually belong together.