Loosening requirements for super() invocation

[Brian Goetz]

We should check each file locally, without regard to whether 
superclasses or subclasses are problematic.

On 11/4/2022 1:38 PM, Archie Cobbs wrote:
> On Fri, Nov 4, 2022 at 12:13 PM Brian Goetz <brian.goetz at oracle.com> 
> wrote:
>
>
>>     So with the FilteredSet example:
>>
>>       * FilteredSet's constructor should generate warning A for not
>>         assigning this.filter prior to super()
>>       * HashSet's constructor should generate warning B for invoking
>>         the potentially this-leaking method addAll()
>>
>
>     I'm not about that direction for the FilteredSet example. The
>     basic problem is that HashSet's constructor calls an overridable
>     method, addAll, which in turn invokes the add override in
>     FilteredSet.  This is a this-escape (even if filter is initialized
>     before super, because FilteredSet could be subclassed and override
>     add.)
>
>     The conclusion that "the problem would go away if we could set the
>     filter first" merely moves the problem around.
>
>
> Right. I agree that HashSet's constructor invoking addAll() is its own 
> problem, and should generate a warning on its own.
>
> So I guess the question is: in the case of FilteredSet, should we 
> generate a warning simply because we know there exist this-leaking 
> superclasses out there, and HashSet might be one of them? It's like 
> warning someone not to leave their doors unlocked. If a crime occurs 
> it's not their fault, but the warning might be useful nonetheless.
>
> On the other hand, such a warning would not be practical: today it 
> would flag every class not directly extending java.lang.Object that 
> has any final fields!
>
> A better answer would be a "best effort" warning that would only occur 
> if the compiler were able to actually observe this-leaking behavior in 
> the superclass. Not sure how practical that is to implement though.
>
> -Archie
>
> -- 
> Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20221104/5bce03ce/attachment.htm>