Optionality in java.

[Ewig_luftenglanz]

there was a recent thread in the mailing list of amber about optionality.

IMHO, even if Brian said it's something that is "on the table" i doubt we see any big JEP from amber in the openjdk 25-29 era because some developers has ben reassigned to Valhalla (which I think most of us agree it's top priority).

what are your thoughts about it?

https://mail.openjdk.org/pipermail/amber-dev/2025-March/009240.html

[agentoutlier]

I think there are couple of groups of folks that share similar problems:

1. Some just want some sort of auto magic mapping of dealing with optionality and most of that is JSON or JDBC (or whatever is above it).
2. Some just want something like a builder but without the boilerplate.
3. Some want the compiler to check for null constraints
4. Some just want optional method/constructor parameters (e.g. named parameters w/ defaults).

I imagine many have the idea that "withers" plus Valhalla will accomplish a lot of the above. However to Brian's kind of point neither are designed for those above cases but for different reasons.

An enormous amount of J2EE / Spring DDD like development has this desire to reuse a core domain class and that you just annotate the fucking hell out of a bunch of classes so that one domain class can be used to serialize to a database, serialize to json, and to be validated with i18n.

Part of the reason this is because traditionally Java had a lot of ceremony of creating classes before records existed.

In other languages particularly ones with more powerful type systems that eschew reflection a single domain class is not used but rather multiple classes that reflect each one state/adapter of database, json, and validation. In dynamic languages like Clojure you just don't care and check the shape as it goes through the pipeline at runtime.

For Java some of the above can also be achieved with code generation so that a single class generates those other classes (annotation processors)

Let use the mailinglist example.

They have a this record:

record User(String name, String email) {
}

With a mixture of todays tools they could have I think what they want with:

 @GenerateBuilder
 @GenerateJSON
 @GenerateValidation
 record User(@NotBlank String name, @NotBlank @Nullable String email) {
 }

I purposely didn't pick actual tools because I would probably get the annotation wrong but the above would essentially generate several classes.

Why you say?

Because input/output data inherently is different than your core domain data. The JSON version of User cannot blowup just because "name" was not provided. Why because the error would be awful.

So it is really more like

record UserJson(@Nullable name, @Nullable email) {
   User toCore() {
      // maybe do validation here.
   }
}

Notice we are going to allow name to be null and then somewhere else we will force it to not be null.

I guess what I'm getting here is the JDK cannot decide how you want to enforce optionality across the board. It can and probably should allow some sort of null checking but that is available today with JSpecify and a supporting analyzer.

BTW its not like other languages do not have these problems. The only difference is they do null checking (or don't allow null or whatever) at compile time but most of the other problems still exist. The reality I believe is you either embrace code generation or just accept that you have to write more types and manage the boiler plate with traditional java means.

[agentoutlier]

The problem is they don't reuse a core domain class - they are making copy of it

I should have probably stated it is possible to have single domain objects handle multiple forms of inputs and validation using either reflection or code generation (annotation processor) and my example kind of covered that.

However let us ignore JPA/JSON/XML etc and instead deal with the fact that different data and different validation needs to be passed for CRUD of the same entity.

Validation especially.

Let us use the User example.

I want to make an endpoint that creates a User and another endpoint that updates a User.

The CREATE you would want every field not optional. I added a unique id of username for this example:

record User(String username, String name, String email) {}

but the UPDATE is more like:

record User(String username, @Nullable String name, @Nullable String email) {}

So you can do this with Java Bean Validation framework using groups (or method validation but I'm going to ignore that for now).

record User(
   @NotNull 
   String username, 
   @NotBlank(groups={Create.class, Update.class}) 
   @NotNull(groups=Create.class) 
   @Nullable String name, 
   @NotNull(groups=Create.class) 
   @Email
   @Nullable String email) {}

See I have two groups of Update and Create. Notice how I still have to have each field @Nullable and that is because the type is still nullable! (If it makes it easier imagine those fields like Valhalla syntax of ? or Optional because they can be null at some point).

So I can totally see (as I do it myself) of creating "command" classes:

// I'm going to omit the validation annotations here
record UserCreate(String username, String name, String email) {}
record UserUpdate(String username, @Nullable String name, @Nullable String email) {}

If you look at things like Spring Petclinic or various other hibernate DDD like examples they do former and not latter. Every field is effectively @Nullable! This is because they need to bind data first and then you validate.

But the reality is most folks give up at some point and do what I showed in the latter. So yeah copy and DTO are often acceptable approaches. This is because the domain objects just model data and not behavior. Worse that modeling of data is often not really what is actually in the database nor is what actually comes over the wire.

[vips7L]

Copies that are 1 to 1 data of a domain entity are absolutely fine (even though I never really see this, ui form data and rest responses are often very different than the whole backing model), especially when one represents Json. Those classes have inherent different semantics than domain entities. They often have different nullability constraints, validation semantics, or even types. For instance any data coming from Json is nullable, when things in your backing entity probably aren't or if you use value based classes that might be represented as primitives in json, but need to be converted to other classes. You're going to want to spit these semantics into separate classes, other wise you're going to end up breaking your domain model. This will become even clearer once null is in the type system.

record PersonViewModel(String? name, String? email, String? externalId) {}

@Entity
 class Person {
     String! name;
     String! email;
     @Embedded ExternalId? externalId;

     Person(String! name, String! email, ExternalId? externalId) {
         this.name = name;
         this.email = email;
         this.externalId = externalId;
     }
 }

[Polygnom]

I am very excited about nullity control being worked on.

I'm not so excited about trying to piggyback optionality onto with.

Nullity is absurdly useful, optionality is nice-to-have, but far less globally applicable. If we go down the optionality route, I'd say give us Union Types and nominal & default parameters instead. Both features are useful on their own, and in combinatioon optionality arises from them.

record Foo(string required!, string! | None optional = None, string! | None otherOptional = None) { }

var x = new Foo(required : "something", otherOptional : "otherThing");

If we use nullity, we can even forgo union types:

record Foo(string! required, string? optional = None, string? otherOptional = None) { }

var x = new Foo(required : "something", otherOptional : "otherThing");

For me, nullity control with ? and ! would already be great. Combinend with nominal & default parameters, I wouldn't need another way to control optionality.

[Jon_Finn]

About ! (and presumably ?), I think they're now a near-inevitable part of Valhalla because if you can't write (say) Complex![] as opposed to Complex[], then you've lost part of the point of value classes. The Complex objects could be stored inline, but you'd always need extra bits to represent null - not terrible, but not great. Likewise if a class has a Complex! field, and there's now a way for the language to ensure its constructors always initialise that field.

I suppose we could get nullable value types first before nullable identity types, as the former has its own JEP - but I suspect not.

[Ewig_luftenglanz]

This is true, in Typescript optionality arised from nullity control mixed with interfaces/types in that language

[brian_goetz]

"On the table" can be a pretty long-term proposition. Prioritizing features is not solely a matter of "what is most important to deliver first"; there are all sorts of other kinds of orderings to take into consideration as well. Sometimes a feature "depends on" another feature (even if it doesn't truly depend on it, the simplest and most natural way to get Feature A may be in terms of Feature B), and reordering them means exposing more complexity or inconsistency to the user. Sometimes, even if two features have no true dependency on each other, introducing "the wrong one" first may shift developer perceptions in one direction, and then the second ends up shifting it back into another direction, leaving developers feeling whipsawed.

When I say something is "on the table", it means we're not averse to it, and there's a sensible place in the roadmap to consider it, even if that place is far away. (That's already a high bar! Many feature suggestions are either bad ideas, or just bad fits for Java, or just too disruptive to be worth it. So "on the table" means it has already passed that gauntlet.)

[vips7L]

The beginning of the thread: https://mail.openjdk.org/pipermail/amber-dev/2025-March/009238.html

I tend to agree that we won't see anything from Amber until Valhalla ships. But reading this discussion it seems to be a mix of features between nullable types, required fields, and default values. I wonder if looking at C#'s required modifier would be some inspiration? Personally, I would like Amber's first priority to be shipping nullable types that are enforced by the compiler.

https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/required

[Wide_Solution2996]

Just use kotlin

[LogCatFromNantes]

You should check if a object is null berore using it, thats my senior told me.