True: this compiles and the test passes today on JDK 27-jep401ea3:
record Person(String name, Age age, Iban iban) {}
// {"name": "SuperMario", "age": null, "iban": null}
Person result = mapper.readValue(json, Person.class);
assertThat(result.age()).isNull(); // passes — value class field, null
assertThat(result.iban()).isNull(); // passes — value class field, null
Jackson bypasses the constructor for null JSON tokens (getNullValue() short-circuits), so the
validation in new Age(...) never runs. Both Age and Iban are value classes; both fields are null.
What do you think? Of course, there are limitations as Person cannot be flattened anymore but I guess Valhalla will ship more JEPs later?
Unfortunately, the simple fact is that one can be handed a JSON document with non-existent keys, and one can be handed a database row with a null column. Often, the programmer may handed a schema from a third party they have no control over: opening a semantics debate is likely not a good course of action.
I guess since basic types, like an int or double, cannot be null, I understand why these cannot be null. This unfortunately limits their usefulness, but it's a carryover from the underlying properties of the basic type.
Value types will be optionally null. What java will introduce to the tooling is narrowing of nullness types. Hence Foo! <: Foo? <: Foo. This will assist in enabling safe domains or scope in code that are null-restricted with ease. Hence we can model around such a type system rule.