JEP 468 updating non-updatable fields

[Holo The Sage Wolf]

It seems like the problem is the flexibility combined with the ease of use.

Fundamentally, if you represent *mutation* using records you are bound to
have mismatches between different levels of the application.

Trying to mutate a record in a db using Java's record is bound to create
problems.

Similarly, trying to respect db record (whose identity is a *specific
column/list of columns*) as data-as-identity constructs (record/carriers)
will also have mismatches.

No amount of language level features will solve this.

To bridge the gap you would need to wrap the API with some construct that
make the identity immutable.

Until now the problem is not too bad because to "make a stupid mistake"
takes effort, but with Withers it becomes easy. To solve this problem
without introducing new languages level type (adding language level
annotation to specific fields is something I would call a new language
level type) we would need to do something like "wither-validator":

record DbRecord(long id, String f0, String f1, ...) {
    withCheck(DbRecord newValue) {
         if (newValue.id() != this.id()) throw ...
    }
}

Which the JVM calls automatically after the wither expression ends but
before it returns the value. So

myRecord with { id+1 }

Will throw runtime exception. I'm not sure how worth this feature is.

Holo The Wise Wolf Of Yoitsu

On Mon, 26 Jan 2026, 18:26 Brian Goetz, <brian.goetz at oracle.com> wrote:

>
> > If we conceive of carrier classes as mostly "record-like but..." Then
> > I think what we tell people to do won't have changed. It's really just
> > that there's a new "wrong" thing that can be done that will be
> > tempting to do.
>
> The semantic description is that a carrier class / component class /
> data class (shed to be painted later) has a complete, canonical, nominal
> description of its state.  IOW, that the carrier _is_ the data, just
> like records -- its just you get more flexibility in representation, aka
> "more rope".
>
> The question of this thread is, "is this too much rope".
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20260126/1cee987c/attachment.htm>