Fwd: An improvement request on records

[Brian Goetz]

The below was received on amber-spec-comments.

The author makes a renewed plea for final, non-component fields in records.

This point was discussed extensively during the design of records, so I 
won't recapitulate the discussion here.


-------- Forwarded Message --------
Subject: 	An improvement request on records
Date: 	Thu, 11 Dec 2025 15:27:28 +0100
From: 	Kai Hofmann <java at kai-hofmann.de>
To: 	amber-spec-comments at openjdk.org



To whom it may concern,

I am working here since some years on my OpenSource projects, and until 
now I had never a reason to made comments on Java - but now I feel I 
have to raise my voice on records:


Since some years I developed a library of DDD valueObjects both as 
normal Java objects and also in a parallel branch as records. At the 
moment you can find this work here:

https://github.com/PowerStat/Validation

But I plan to rename this project, because in the meantime the project 
name is no longer a good choice - maybe it will name something like 
ValueObjectLibrary - you will find it under my github repos.


So from my experiences I can say it is a correct design decision to not 
have instance fields within records.

But in my opinion this thought is to simple, because private "final" 
instance fields should be possible and will be useful and could safe 
duplicated code as well as runtime!

So the point is that final instance fields have to be initialized within 
the constructor and will be unchangeable after a record has been 
constructed - so they are harmless!

As an example I have implemented a MACAddress class/record that 
represents a hardware mac address.

Within the normal class implementation I split the mac address into it's 
parts only once within the construtor, later on I have multiple methods 
that work on this split parts.

But within a record this is not possible so I have to do the split 
within every method where I need it - thats waste of code and runtime!

Another example is my implementation of the ISBN13 - see 
https://en.wikipedia.org/wiki/ISBN

These numbers could come with 2 different formats: with or without 
separator chars in it - both formats are equal.

So in my class implementation I would do a normalization (without 
separators) and store this one internally.

Within a record this normalization in the construtor is not possible, 
because I could not have instance fields nor could I change the records 
parameter within the constructor because its already fixed :(

So ISBN13 could not be implemented as a record!

I vote for extending the record specification to have private "final" 
instances within it and maybe to allow to manipulate the construction 
parameters within the constructor.

Would be nice to hear from you about this.


Greetings and have a nice Christmas and a Happy New Year.


PowerStat (Kai Hofmann)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-spec-experts/attachments/20251211/7518b03c/attachment.htm>