Field initialization before 'super'
Archie Cobbs
archie.cobbs at gmail.com
Wed Dec 13 21:19:56 UTC 2023
On Wed, Dec 13, 2023 at 3:07 PM <forax at univ-mlv.fr> wrote:
>
> captured fields in lambda are like strict but captured fields is inner
>> classes are like normal fields.
>>
>
> I was curious why this would be true and it appears it's not true, at
> least from this test:
>
>
> Yes, but you can still change the value of the field by reflection, unlike
> with the fields of a lambda proxy, so the field containing the captured
> value is not strict.
>
Thanks for the clarification, I missed that piece of it.
> My opinion is also "no" on this question... but because it would add
> another logical fork in developers' minds for too little benefit. It's easy
> enough to just put it in there explicitly.
>
>
> What we are trying to do here, is to follow Dan's idea that there is no
> need for an additional keyword and that the compiler can infer the
> strictness by itself.
> As you said, the problem of that idea is that the developer is not really
> in control, subtle changes like the initializer depending on 'this' make
> the final field strict or not.
>
So it would boil down to the difference between:
private final int x; // not strict
Foo(int x) {
// implicit super() goes here
this.x = x;
}
vs.
private final int x; // implicitly strict
Foo(int x) {
this.x = x;
// implicit super() goes here
}
which only differ in behavior in the introspection and serialization
domains.
Thanks - now I get it.
-Archie
--
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-spec-observers/attachments/20231213/0f55c33b/attachment.htm>
More information about the amber-spec-observers
mailing list