Possible records tweak

[Brian Goetz]

I think Guy's concern is that you could cause code to _read_ an 
uninitialized, final field?  Of course, we have this problem all over 
the place today, so having it in records does not make things 
significantly worse.

On 4/29/2020 2:47 PM, Dan Smith wrote:
>
>> On Apr 29, 2020, at 12:35 PM, Guy Steele <guy.steele at oracle.com> wrote:
>>
>>
>>
>>> On Apr 29, 2020, at 2:23 PM, Dan Smith <daniel.smith at oracle.com> wrote:
>>>
>>>
>>>> On Apr 29, 2020, at 11:28 AM, Guy Steele <guy.steele at oracle.com> wrote:
>>>>
>>>> Appealing, but it does raise the question of whether, if the programmer uses some sneaky trick such as calling super, this can really be enforced ar compile time on all cases. If it can (after all), then your proposed wording looks good to me.
>>> The idea would be to rely on the definition of "assign to" in JLS 16. That uses a heuristic that counts "x =" or "this.x =" (and, in javac, but not currently specified properly, "(this).x", etc.)
>>>
>>> Stepping back: in general, it's illegal to assign to a final field. There's one exception: inside a constructor, where the field is DU, using an assignment that satisfies the heuristic. In any other case, you get an error.
>>>
>>> So the language has carved out a small hole permitting assignments, and this rule closes that hole.
>> That's all very good.
>>
>> But I'm worried about cases where you use some escape catch such as calling super or a static method, passing it "this" as an argument if necessary, and arriving at a place where you need to solve the halting problem to decide at compile time whether the forbidden behavior might occur.  I haven't swapped all the current rules back into head enough to decide for myself whether this sort of scenario can actually arise.
> I'm leaning heavily on "in general, it's illegal to assign to a final field".
>
> If you try to construct your exploit, you will find that when you try to assign to the field, you'll get a "can't assign to final field" error.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20200429/2daa3cce/attachment.htm>