Loosening requirements for super() invocation

[Brian Goetz]

> 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.




> This sounds like the right logical separation. One confirmation is 
> that correcting /either one/ of the warnings would fix the bug. So 
> each class must be independently contributing to the overall danger level.
>
>     To your point about "the superclass might downcast", this is
>     something you can check for as something questionable to do with
>     `this`.
>
>
> Agreed - this should also generate warning B, because it represents a 
> possible route for 'this' to escape.
>
> -Archie
>
> -- 
> Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20221104/b55ef2b6/attachment.htm>