[Records] Why components are not readOnly
brian.goetz at oracle.com
Tue Jan 21 17:36:12 UTC 2020
First, remember that modifying final fields is wholly outside of either
the language or VM specification. (And I can't imagine any universe
where the word "basic" and modifying final fields through
Unsafe+reflection go in the same thought, let along the same sentence...)
I truly understand the motivation here; you want to at least prevent the
problem from getting worse. But, such thinking is often a siren song
that crashes you on the rocks of complexity (and becomes yet another
subtle way in which records and classes can't be migrated to each other.)
This was discussed already, and the consensus of both language and VM
architects was that this is a problem to be solved more generally, not
by tacking weird corner-case behavior in a dozen different places.
Let's not load the record bus up with extra complexity just because it
happens to be leaving soon.
On 1/21/2020 4:48 AM, Bruno Borges wrote:
> A field that is static and final is by definition, readOnly . See this
> sample  for a comparison between Java 1.8 and 11 versus 13 and 14.
> Is there a reason why Record components aren't protected from basic
> reflection access and modification as static final constants are? And what
> could be the possible downsides of turning Record components into readOnly?
>  https://asciinema.org/a/grviUuzbf3IViR08FqHxC79WE
> *Bruno Borges*
More information about the amber-dev