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