JEP 468 updating non-updatable fields

[Holo The Sage Wolf]

Maybe I wasn't clear enough.

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

I meant something along the lines of Brian's method. My toy example was to
demonstrate another possible solution to how to solve the issue at language
level *if we were to decide this is were it should be solved there*.

I do not wish to put this idea as a suggestion for a language improvement.

Holo The Wise Wolf Of Yoitsu

On Mon, 26 Jan 2026, 21:04 Mahied Maruf, <contact at mechite.com> wrote:

> > Holo The Sage Wolf says:
> > 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.
>
> I think it's important to understand this semantic distinction
> properly.  You proposed a syntax to prevent derivation of an existing
> record if the identifier was changed, but to me this seems also like a
> case that could make sense and enforcement of it should be part of the
> database layer (ORM etc).  Brian proposed that a seperate class
> (or record) could be used just for the identifier and I both agree
> with this mental model and am already seeing it being done in e.g.
> representation of concatenated primary key where it already is much
> more intuitive to perform validation (among other things) this way.
>
> Best regards,
> Mahied Maruf <contact at mechite.com>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20260126/0d10d55c/attachment-0001.htm>