<div dir="ltr"><div dir="ltr">On Fri, Nov 4, 2022 at 12:13 PM Brian Goetz <<a href="mailto:brian.goetz@oracle.com">brian.goetz@oracle.com</a>> wrote:<br></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>
    <br>
    <blockquote type="cite">
      <div dir="ltr">
        <div class="gmail_quote">
          <div>So with the FilteredSet example:</div>
          <div>
            <ul>
              <li><span style="font-family:monospace">FilteredSet</span>'s
                constructor should generate warning A for not assigning
                <span style="font-family:monospace">this.filter</span>
                prior to <span style="font-family:monospace">super()</span></li>
              <li><span style="font-family:monospace">HashSet</span>'s
                constructor should generate warning B for invoking the
                potentially this-leaking method <span style="font-family:monospace">addAll()</span><br>
              </li>
            </ul>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    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.)  <br>
    <br>
    The conclusion that "the problem would go away if we could set the
    filter first" merely moves the problem around.</div></blockquote><div><br></div><div>Right. I agree that <span style="font-family:monospace">HashSet</span>'s constructor invoking <span style="font-family:monospace">addAll()</span> is its own problem, and should generate a warning on its own.</div><div><br></div><div>So I guess the question is: in the case of <span style="font-family:monospace">FilteredSet</span>, should we generate a warning simply because we know there exist this-leaking superclasses out there, and <span style="font-family:monospace">HashSet</span> 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.</div><div><br></div><div>On the other hand, such a warning would not be practical: today it would flag every class not directly extending <span style="font-family:monospace">java.lang.Object</span> that has any final fields!</div><div><br></div><div>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.<br></div><div><br></div><div>-Archie<br></div><br></div>-- <br><div dir="ltr" class="gmail_signature">Archie L. Cobbs<br></div></div>