Loosening requirements for super() invocation

[Archie Cobbs]

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/379286d0/attachment-0001.htm>