[concurrency-interest] lazy finals - was: Here's why Atomic*FieldReference access checking is broken

Aaron Grunthal aaron.grunthal at infinite-source.de
Thu Oct 9 12:29:17 EDT 2014

On 09.10.2014 17:21, Peter Levart wrote:
> This would be a cool optimization for mostly read-only and rarely
> updated fields, but do we want to transform final instance fields into
> such thing just to support deserialization via reflection? If this is
> not a big deal to support than perhaps it is a better approach since it
> does not neglect null/zero values.

I think the issue here may be that final is used to signal two slightly 
distinct purposes.

1. It's to tell the compiler: "This data (almost) never changes, please 
optimize aggressively, I'm willing to take a significant performance hit 
if I ever have to change it via reflection"
This might also be relevant for other language implementers, e.g. for 
jruby class variables and constants which should remain constant but can 
be easily changed via metaprogramming or initialized multiple times by 
various modules.

2. It's to tell users of the class that it's immutable data, it's safe 
to pass around, that they're doing something wrong if they want to 
change the value, etc.
Think value-types.
Since immutable data objects are often ephemeral and not assigned to 
static fields the programmer doesn't really expect the compiler to 
perform constant folding.
It's also where the deserialization problem commonly occurs.

- Aaron

More information about the Concurrency-interest mailing list