RFR: 8193904: Uninitialized final field access and qualified this

[Archie Cobbs]

It looks like nobody wants to do anything about this issue.

If that's the case, could someone please close JDK-8193904
<https://bugs.openjdk.org/browse/JDK-8193904> (and then I'll retract my PR)?

Thanks,
-Archie

On Fri, Nov 18, 2022 at 9:49 AM Archie Cobbs <archie.cobbs at gmail.com> wrote:

> On Wed, Nov 2, 2022 at 3:18 PM Archie Cobbs <archie.cobbs at gmail.com>
> wrote:
>
>> On Wed, Nov 2, 2022 at 2:47 PM Alex Buckley <alex.buckley at oracle.com>
>> wrote:
>>
>>> JLS ch.16 is specific that only `foo` and `this.foo` cause an error. See
>>> the definition of "access" in the opening paragraphs of the chapter.
>>>
>>
>> Thanks for pointing that out, which I forgot to do. The JLS language is:
>>
>> An access to its value consists of the simple name of the variable (or,
>> for a field, the simple name of the field qualified by this) occurring
>> anywhere in an expression except as the left-hand operand of the simple
>> assignment operator =
>>
>> In theory one could argue that MyClass.this.foo is also an example of
>> "the simple name of the field qualified by this" - just look at the
>> latter part, no?
>>
>> Regardless, it looks like there needs to be a spec change... right? I'm
>> assuming we'd rather do that than continue to allow the current behavior.
>>
>
> Any further thoughts on this one?
>
> It seems to me that regardless of what you think the right answer is, the
> current situation could use some improvement.
>
> Here's how the compiler currently behaves:
>
> // This class compiles without error
> public class Example1 {
>     final int foo;
>     public Example1() {
>         System.err.println(Example1.this.foo);  // no error generated here
>         this.foo = 42;
>     }
> }
>
> // This class fails to compile
> public class Example2 {
>     private final int foo;
>     public Example2() {
>         Example2.this.foo = 42; // "cannot assign a value to final
> variable foo"
>     }
> }
>
> My thoughts...
>
>    - If the compiler is not following the spec, then we need to fix the
>    compiler
>    - If the compiler is following the spec, then shouldn't the spec be
>    corrected so that it treats Foo.this and this the same way?
>
> In another email Alex said:
>
>> DU/DA analysis is about whether names have bindings. `x.foo` and `new
>>
> C().foo` and `m().foo` are expressions, not names, so we don't attempt
>> the analysis on them. As Jan points out [1], access via expressions is
>> hard to track. `this.foo` is an expression, but a very easy one, so we
>> treat it like the name `foo` and do the analysis. `A.B.C.this.foo` is an
>> expression with a qualified-this subexpression and now you need a bunch
>> of analysis to figure out whether it means the same as the name `foo`.
>
>
> I don't see that you "need a bunch of analysis". The required analysis is
> already being done, for example, when handling expressions that could refer
> to outer 'this' instances. We're not talking about arbitrarily complex
> expressions. The only two options are 'this' or 'this' qualified by a type
> name.
>
> Apologies if I'm missing something, just trying to understand what the
> issue is here.
>

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20221128/1f67e68b/attachment.htm>