this-escape

[Archie Cobbs]

Hi Stephan,

We were conservative in choosing which subclasses should be considered
possible "victims" in a this-escape scenario. This was done to help avoid
false positives.

Specifically, classes in the same package are assumed to be "in the know"
with respect to the leaking superclass and so we don't worry about them
being "victims".

To put that in concrete terms: If you change your constructor Y() to be
protected then you will get the warning. When it's package-only access, the
compiler assumes it's not possible for there to be a true "victim".

There are some notes to this effect at the top of ThisEscapeAnalyzer.java.

-Archie

On Tue, Apr 22, 2025 at 1:59 PM Stephan Herrmann <stephan.herrmann at berlin.de>
wrote:

> Just now and by chance I found https://bugs.openjdk.org/browse/JDK-8015831
>
> I tried to provoke this warning in the most obvious way I could think of:
>
> public class Y {
>         Y() {
>                 m();
>         }
>         void m() {}
> }
>
> public class X extends Y {
>         String s = "Hello";
>         @Override void m() {
>                 System.out.print(s);
>         }
>         public static void main(String... args) {
>                 System.out.print(new X().s);
>         }
> }
>
> Much to my surprise javac -Xlint:all keeps quiet (all recent versions).
>
> Running java X of course demonstrates that s is read before its
> initialization,
> exactly for that reason that Y() invokes an overridable method.
>
> Where can I learn about the rules behind this validation?
>
> thanks,
> Stephan
>
>
>
>

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20250422/1b429352/attachment.htm>