RFR: 8193904: Uninitialized final field access and qualified this

[Alex Buckley]

IIRC this javac change first requires a JLS change to specify the 
analysis of the receiver (the entity whose self is being accessed via 
qualified this).

Alex

On 11/29/2022 9:40 AM, Vicente Romero wrote:
> Hi,
> 
> I think that given that we are so close to closing the development for 
> 20 that we push this early on 21 after the fork for 20 has been done,
> 
> Thanks,
> Vicente
> 
> On 11/28/22 12:45, Archie Cobbs wrote:
>> 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
>