<div dir="ltr"><div>Regarding 'this' escape, folks may have already seen the blizzard of PR comments but I thought I'd pull out <a href="https://github.com/openjdk/jdk/pull/11874#discussion_r1071455800" target="_blank">this one</a> from @mcimadamore as particularly interesting from a design perspective:</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>To be fair, this is what my brain was reading when you talked about 
"compilation unit" - but then saw that the code was doing it 
differently. You see, for "sealed" classes we have a notion of 
"maintenance domain". E.g. the classes in a <code>permits</code> clause of a <code>sealed</code>
 declaration must belong to the same module (if available) or same 
package (if no module is available). That's how you get the 
exhaustiveness analysis and all the goodies, by essentially making a 
close-world assumption on the classes that are passed to javac for a 
given compilation task. I think it would make a lot of sense to apply 
these very same boundaries to the escape-this analysis (and, in fact, 
when looking at warnings coming out of the JDK, I often found false 
positives that were caused by this).</div></blockquote><div><br></div><div>Any thoughts? Should we define the "boundary of concern" differently for sealed classes?<br></div><div><br></div><div>-Archie<br></div><div><br>-- <br><div dir="ltr">Archie L. Cobbs<br></div></div></div>