[Records] Why components are not readOnly

[Brian Goetz]

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.

https://mail.openjdk.java.net/pipermail/amber-spec-experts/2019-November/001792.html


On 1/21/2020 4:48 AM, Bruno Borges wrote:
> Hi,
>
> A field that is static and final is by definition, readOnly [1]. See this
> sample [2] 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?
>
> [1]
> https://github.com/openjdk/jdk14/blob/master/src/java.base/share/classes/jdk/internal/reflect/UnsafeFieldAccessorFactory.java#L38
> [2] https://asciinema.org/a/grviUuzbf3IViR08FqHxC79WE
>
> ---
> *Bruno Borges*