Loosening requirements for super() invocation

Archie Cobbs archie.cobbs at gmail.com
Mon Jan 16 18:02:13 UTC 2023


Regarding 'this' escape, folks may have already seen the blizzard of PR
comments but I thought I'd pull out this one
<https://github.com/openjdk/jdk/pull/11874#discussion_r1071455800> from
@mcimadamore as particularly interesting from a design perspective:

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 permits clause of a sealed 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).
>

Any thoughts? Should we define the "boundary of concern" differently for
sealed classes?

-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20230116/0d7bf35d/attachment-0001.htm>


More information about the amber-dev mailing list