I would strongly suggest you stop using this pattern. It's got all sorts of problems:

Basic errors in the code

Your NULL_ID field isn't final which it clearly should be.

Null object vs. Empty object

There are 2 concepts that seem similar or even the same but they aren't.

There's the unknown / not found / not applicable concept. For example:

Map<String, Id> studentIdToName = ...;
String name = studentIdToName.get("foo");

What should name be if "foo" is not in the map?

Not so fast - before you answer: Well, maybe "" - that would lead to all sorts of problems. If you wrote code that mistakenly thinks the id used is definitely in this map, then it's a fait accompli: This code is bugged. Period. All we can do now is ensure that this bug is dealt with as 'nicely' as possible.

And saying that name is null here, is strictly superior: The bug will now be explicit, with a stack trace pointing at the offending code. Absence of stack trace is not proof of bug free code - not at all. If this code returns the empty string and then sends an email to a blank mail address with a body that contains an empty string where the name should be, that's much worse than the code throwing an NPE.

For such a value (not found / unknown / not applicable), nothing in java beats null as value.

However, what does occur quite often when working with APIs that are documented to perhaps return null (that is, APIs that may return 'not applicable', 'no value', or 'not found'), is that the caller wants to treat this the same as a known convenient object.

For example, if I always uppercase and trim the student name, and some ids are already mapped to 'not enrolled anymore' and this shows up as having been mapped to the empty string, then it can be really convenient for the caller to desire for this specific use case that not-found ought to be treated as empty string. Fortunately, the Map API caters to this:

String name = map.getOrDefault(key, "").toUpperCase().trim();
if (name.isEmpty()) return;
// do stuff here, knowing all is well.

The crucial tool that you, API designer, should provide, is an empty object.

Empty objects should be convenient. Yours is not.

So, now that we've established that a 'null object' is not what you want, but an 'empty object' is great to have, note that they should be convenient. The caller already decided on some specific behaviour they want; they explicitly opted into this. They don't want to then STILL have to deal with unique values that require special treatment, and having an Id instance whose id field is null fails the convenience test.

What you'd want is presumably an Id that is fast, immutable, easily accessible, and has an empty string for id. not null. Be like "", or like List.of(). "".length() works, and returns 0. someListIHave.retainAll(List.of()) works, and clears the list. That's the convenience at work. It is dangerous convenience (in that, if you weren't expecting a dummy object with certain well known behaviours, NOT erroring on the spot can hide bugs), but that's why the caller has to explicitly opt into it, e.g. by using getOrDefault(k, THE_DUMMY).

So, what should you write here?

Simple:

private static final Id EMPTY = new Id("");

It is possible you need for the EMPTY value to have certain specific behaviours. For example, sometimes you want the EMPTY object to also have the property that it is unique; that no other instance of Id can be considered equal to it.

You can solve that problem in two ways:

1. Hidden boolean.
2. by using EMPTY as an explicit identity.

I assume 'hidden boolean' is obvious enough. a private boolean field that a private constructor can initialize to true, and all publically accessible constructors set to false.

Using EMPTY as identity is a bit more tricky. It looks, for example, like this:

@Override public boolean equals(Object other) {
    if (other == null || !other.getClass() == Id.class) return false;
    if (other == this) return true;
    if (other == EMPTY || this == EMPTY) return false;
    return ((Id) other).id.equals(this.id);
}

Here, EMPTY.equals(new Id("")) is in fact false, but EMPTY.equals(EMPTY) is true.

If that's how you want it to work (questionable, but there are use cases where it makes sense to decree that the empty object is unique), have at it.

null is a bit of an odd beast in java; it means too many things if you take a wide survey across the community.

But that doesn't mean you should make the same mistake. null is best left as a thing you 'tighten' - it needs to mean something highly specific. And that specific thing is: "Unknown / irrelevant / not set".

Here's the difference:

If I hold my 2 hands behind my back with closed fists, and I ask you: "Are the object that I hold in my left hand, and the one in my right hand, equal?" - then you should ask me to show you the objects. If I refuse, the answer is not "They are equal". The answer is also not "They are different". The only right answer is "I cannot tell."

Hence, this java code:

Copypublic void whatever() {
  String a = null;
  String b = null;
  if (a.equals(b)) { ... }
}

Actually does the right thing: It throws an NPE which is what you want. Similarly, asking for the length of an unknown thing is best answered with 'I do not know'. The answer: "It has 0 length" is not appropriate.

By approaching null that way, i.e. by ensuring you never use it as a standin for 'empty' or 'default' or similar, the NullPointerException turns into an asset instead of a nuisance. You want that exception.

Hence, the right approach is in fact this:

Copypublic record Car(
        long id,
        String model,
        List<Wheel> wheels
) {
    public Car {
        Objects.requireNonNull(wheels, "wheels");
    }
}

The constructor of records is the right place for checking preconditions, and this is a precondition: The list is required to be non-null. You might also want to require that model isn't null either.

A clue you're doing it wrong is if you write if (x == null || x.isEmpty()) a lot. After all, if 'null' and 'empty' are treated as semantically equivalent pretty much all the time then why is null a thing in the first place? It's not hard to make an empty thing. In fact, for strings, it's easier: "" is shorter to write than null and takes, if anything, less memory (the empty string is interned, don't worry about that).

Your callers shouldn't be overly bothered, they can just pass List.of() which is not much to type and far easier to read. After all, this:

Copynew Car(0, null, null);
new Car(0, "", List.of());

The second one is more informative; at least you have some vague idea about the types of the arguments, and you also know clearly that the list is supposed to be empty.

null can still make sense, if the concept of 'irrelevant/unknown' is something your record needs to be capable of conveying. For example, if you want to be able to encode the notion of a 'car' that is currently in the garage, with the wheels removed. It still has wheels, we just don't know where they are right now. This is annoying, of course: All code that deals with Car instances needs to be capable of dealing with it. Hence, you only 'do' that (allow null) if it's strictly necessary.

A wheel-less car, that's no problem, and should be represented with List.of(). Not null.

The simple way to think about it is: null should mean something different vs. any other possible value imaginable. If that is true, null is good. If that is not true (for example, null means the same thing as List.of()), then you should throw an NPE as fast as you can (first line of a constructor is a great place).

Immutability

records don't need to be immutable but it tends to be expected. Did you intend for this record to allow the set of wheels to change during its lifetime? If yes, record might not be appropriate. If no, then new ArrayList is not right; you want List.of which guarantees that the list cannot change. It's a bit difficult to enforce that callers pass an immutable list, unfortunately. Best simply not do that (document it instead). Also, List.of() is shorter and (very rarely relevant) more efficient.

A record comprises attributes that primarily define its state. The derivation of the accessors, constructors, etc. is completely based on this state of the records.

Now in your example, the state of the attribute value is null, hence the access using the default implementation ends up providing the true state. To provide customized access to this attribute you are instead looking for an overridden API that wraps the actual state and further provides an Optional return type.

Of course, as you mentioned one of the ways to deal with it would be to have a custom implementation included in the record definition itself

record MyClass(String id, String value) {
    
    Optional<String> getValue() {
        return Optional.ofNullable(value());
    }
}

Alternatively, you could decouple the read and write APIs from the data carrier in a separate class and pass on the record instance to them for custom accesses.

The most relevant quote from JEP 384: Records that I found would be(formatting mine):

A record declares its state -- the group of variables -- and commits to an API that matches that state. This means that records give up a freedom that classes usually enjoy -- the ability to decouple a class's API from its internal representation -- but in return, records become significantly more concise.

JEP 440 indeed says:

The null value does not match any record pattern.

But look carefully at what a record pattern is:

A record pattern consists of a record class type and a (possibly empty) pattern list [...]

The JEP also specified the syntax of a record pattern like this:

Pattern:
  TypePattern
  RecordPattern

TypePattern:
  LocalVariableDeclaration

RecordPattern:
  ReferenceType ( [ PatternList ] )

PatternList : 
  Pattern { , Pattern }

By these definitions, we can see that var x and var y are not record patterns. They are type patterns. The rule that "The null value does not match any record pattern" does not apply to var x and var y.

This rule does apply to the entire Point(var x, var y) pattern, which is a record pattern, so if obj is null, it will not match Point(var x, var y).

I can't find exactly where in the JEP says that type patterns in record patterns behave like this, but the preview spec does state this explicitly:

Consider, for example:

class Super {}
class Sub extends Super {}
record R(Super s) {}

We expect all non-null values of type R to match the pattern R(Super s), including the value resulting from evaluating the expression new R(null). (Even though the null value does not match the pattern Super s.) However, we would not expect this value to match the pattern R(Sub s) as the null value for the record component does not match the pattern Sub s.

The meaning of a pattern occurring in a nested pattern list is then determined with respect to the record declaration. Resolution replaces any type patterns appearing in a nested pattern list that should match all values including null with instances of the special any pattern. In our example above, the pattern R(Sub s) is resolved to the pattern R(Sub s), whereas the pattern R(Super s) is resolved to a record pattern with type R and a nested pattern list containing an any pattern.

In other words, Point(var x, var y) is resolved to Point(<any>, <any>). The <any> pattern here can match everything, including null.

Here's another example:

record Foo(Integer x, Integer y) {}

record Bar(Foo a, Foo b) {}

private static void printSum(Object obj) {
    if (obj instanceof Bar(Foo(Integer x1, Integer y1), Foo(var x2, var y2))) {
        System.out.println("matched!");
    }
}

Now, a new Bar(null, null) would not match the pattern Bar(Foo(Integer x1, Integer y1), Foo(var x2, var y2)), because Foo(Integer x1, Integer y1) is a record pattern, and null does not match it.