<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<font size="4"><font face="monospace">This is an interesting one.
The design of sealed classes deliberately took the unit of
maintenance into account: in the unnamed module, they must be
the same package, and in a named module, they must be in the
same module. I am not sure if we require that they always be
co-compiled; if we already do, then having the analysis cross
the boundary makes sense, but if we permit a sealed nest to be
compiled separately, then it might be weird to only do the
this-escape analysis if they happen to be being co-compiled?<br>
</font></font><br>
<div class="moz-cite-prefix">On 1/16/2023 1:02 PM, Archie Cobbs
wrote:<br>
</div>
<blockquote type="cite" cite="mid:CANSoFxtmYstD2ki42vw0E8iu1rUNAvhWud4pm=bpK+Jf7S=0sg@mail.gmail.com">
<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://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/11874*discussion_r1071455800__;Iw!!ACWV5N9M2RV99hQ!IZznC0UlwtXHI3-jvGUGjvt-p66LYa7TQXYMdn47RPw_H98g1KX4T3UnmOjDoKLkzN5TAcDnGIgTSz142mT7ZuQ$" target="_blank" moz-do-not-send="true">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>
</blockquote>
<br>
</body>
</html>