RFR: 8193904: Uninitialized final field access and qualified this

[Vicente Romero]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20221129/2a60b592/attachment-0001.htm>