Loosening requirements for super() invocation

[Brian Goetz]

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?

On 1/16/2023 1:02 PM, Archie Cobbs wrote:
> Regarding 'this' escape, folks may have already seen the blizzard of 
> PR comments but I thought I'd pull out this one 
> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/11874*discussion_r1071455800__;Iw!!ACWV5N9M2RV99hQ!IZznC0UlwtXHI3-jvGUGjvt-p66LYa7TQXYMdn47RPw_H98g1KX4T3UnmOjDoKLkzN5TAcDnGIgTSz142mT7ZuQ$> 
> 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/f1662e6e/attachment.htm>