<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<font size="4"><font face="monospace">We should check each file
locally, without regard to whether superclasses or subclasses
are problematic. </font></font><br>
<br>
<div class="moz-cite-prefix">On 11/4/2022 1:38 PM, Archie Cobbs
wrote:<br>
</div>
<blockquote type="cite" cite="mid:CANSoFxs1P=mMRipGuMXEW2gKxsALXbxS7omBhcWmwD2PkJbpBQ@mail.gmail.com">
<div dir="ltr">
<div dir="ltr">On Fri, Nov 4, 2022 at 12:13 PM Brian Goetz <<a href="mailto:brian.goetz@oracle.com" moz-do-not-send="true" class="moz-txt-link-freetext">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>
</blockquote>
<br>
</body>
</html>