<div dir="ltr"><div dir="ltr">On Tue, Jan 17, 2023 at 9:51 AM Brian Goetz <<a href="mailto:brian.goetz@oracle.com">brian.goetz@oracle.com</a>> wrote:</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

  
  <div>
    <font size="4"><font face="monospace">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?</font></font></div></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.<br></div><div><br></div><div>At the risk of redundancy, I'll requote this comment from the PR:</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><p dir="auto">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.</p>
<p dir="auto">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.</p>
<p dir="auto">In the big picture, it seems like our goals are roughly:</p>
<ol dir="auto"><li>Be able to detect a high % of the "truly threatening" leaks that are out there (minimize false negatives)</li><li>Keep the implementation relative simple and minimize compiler performance impact</li><li>Try to avoid having so many false positives that developers are turned off or annoyed</li></ol>
<p dir="auto">I think we're pretty good on item 1, although this one somewhat of a speculative judgement call.</p>
<p dir="auto">For item 2 we're in the right ballpark I think... (others may disagree).</p>
<p dir="auto">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.</p>
<p dir="auto">So starting with a less aggressive posture, allowing for getting more so over time, is a the more conservative option.</p>
<p dir="auto">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.</p>
<p dir="auto">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.</p></div></blockquote><div><br></div><div>-Archie<br></div></div><br>-- <br><div dir="ltr" class="gmail_signature">Archie L. Cobbs<br></div></div>