Loosening requirements for super() invocation
Brian Goetz
brian.goetz at oracle.com
Fri Nov 4 18:07:57 UTC 2022
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>
More information about the amber-dev
mailing list