RFR: 8193904: Uninitialized final field access and qualified this

[Archie Cobbs]

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.

Thanks,
-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20221118/7e9ede4c/attachment-0001.htm>