> On Apr 29, 2020, at 12:35 PM, Guy Steele <guy.ste...@oracle.com> wrote:
>
>
>
>> On Apr 29, 2020, at 2:23 PM, Dan Smith <daniel.sm...@oracle.com> wrote:
>>
>>
>>> On Apr 29, 2020, at 11:28 AM, Guy Steele <guy.ste...@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.
