Loosening requirements for super() invocation

[Archie Cobbs]

On Tue, Jan 17, 2023 at 9:51 AM Brian Goetz <brian.goetz at oracle.com> wrote:

> With the relaxation you suggest, it seems like abstract base classes that
> permit this-escape would not be flagged if they are package-private, even
> if the subclasses are themselves public?
>

Yes, we would effectively be widening the "maintenance boundary" from the
compilation unit to the module, but we would not simultaneously be widening
the code that we analyze from the compilation unit to the module. So that
opens up some new indirect "holes" like your example.

The hope however is that these new holes, which represent potential false
negatives, are rare and "module-specific" enough that the trade-off for the
reduced false positives is worth it.

This is all just a SWAG at what the right thing to do is before we really
know how it's going to turn out, and therefore trying to be conservative.

At the risk of redundancy, I'll requote this comment from the PR:

So far we've stuck to the requirement that whatever analysis we are doing
> is done on a a per-file basis, one at a time, so analyzing possible class +
> subclass combinations is currently limited to what's available in a single
> file.
>
> Now this is not an inviolate requirement, and removing it would certainly
> enable the analysis to rule out more false positives (as with your
> example), but it's not something we've really considered doing yet, mainly
> because of item 2 below.
>
> In the big picture, it seems like our goals are roughly:
>
>    1. Be able to detect a high % of the "truly threatening" leaks that
>    are out there (minimize false negatives)
>    2. Keep the implementation relative simple and minimize compiler
>    performance impact
>    3. Try to avoid having so many false positives that developers are
>    turned off or annoyed
>
> I think we're pretty good on item 1, although this one somewhat of a
> speculative judgement call.
>
> For item 2 we're in the right ballpark I think... (others may disagree).
>
> For item 3, this is where there is still some worry and uncertainty. It's
> not just about what kind of leaks/bugs are out there, it's also that it's
> hard to predict how humans will react.
>
> So starting with a less aggressive posture, allowing for getting more so
> over time, is a the more conservative option.
>
> The simplest way to do that is to widen the "maintenance boundary" as
> mentioned. Now this could impact item 1 but at least any new false
> negatives would necessarily be contained within a single package/module.
>
> To restate: we can always get more aggressive if that turns out to be
> warranted. But if you start out too aggressive and the world barfs on it
> and just turns it off, you've probably missed your chance forever.
>

-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20230117/d5361b79/attachment-0001.htm>