Loosening requirements for super() invocation

[Brian Goetz]

There's a few things you could mean by "not worth bothering" here. For 
things within a source file, we can detect when the use of `this` is 
safe, as in:

class Foo {
     Foo() { m(this); }
     private void m(Foo f) { /* nothing */ }
}

and so we could elide warnings for cases like this if we wanted to. But 
in general, what I'm saying is that we should warn when we detect there 
is a *possibility* of a problem, rather than having to prove that there 
*will be* a problem.

The HashMap example is really the kind of code that we want to give 
users feedback on, because people make dodgy self-use from constructors 
all the time, and don't realize they are setting a time bomb.  
Similarly, people enqueue listeners from constructors, and if the 
listener gets called too early ... boom.  These are the things we want 
to detect.  The rest, like the above examples, is trimming away false 
positives.

On 11/9/2022 11:54 AM, Archie Cobbs wrote:
> On Wed, Nov 9, 2022 at 10:38 AM Brian Goetz <brian.goetz at oracle.com> 
> wrote:
>
>
>>     Agreed... that formulation is simpler. But of course it would
>>     need a caveat for subclasses within the same compilation unit, e.g.:
>
>     All these classes are in the same compilation unit, though it's
>     possible you may not want to get fancy enough with the analysis to
>     simulate virtual dispatch (though you could, since its all in the
>     same file.)
>
>
> OK so it sounds like you're saying that it's not worth bothering 
> trying to prevent someone from a 'this' escape that is contained 
> within a single source file, because those cases are relatively easy 
> ones to spot.
>
> Rather, it's in the non-obvious cases, where the problem spans 
> multiple compilation units, that programmers could really benefit from 
> some extra help from the compiler.
>
> This defines a clear & straightforward boundary for the warning.
>
> -Archie
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20221109/bf12f608/attachment-0001.htm>