Java 21 introduces a new this-escape warning which warns against situations where a constructor is calling a method which can be overriden by a subclass. This is a potentially dangerous situation because the overriden method might now depend on fields in the subclass which are not yet initialized because the superclass constructor isn't finished.

I don't understand why the warning is triggering when a class calls a final method which is declared in one of it's own parents.

Here's an example:

package .example;

public class A {
    public final int getNumber() {
        return 10;
    }
}

public class B extends A {
    public B(){
        getNumber(); // Compiler warns here:
                     // warning: [this-escape] possible 'this' escape 
                     // before subclass is fully initialized
    }
}

Is there a way that B can be extended which would cause a problem? If getNumber() was not final then a subclass of B could potentially break itself, but I don't see the error condition here.

A potential problem is if the superclass method calls another non-final method. Assuming that that not the case, is there still an error condition?

I can't tell if this warning is a false positive, or a very esoteric error I don't understand.

Java 21 introduces a new this-escape warning which warns against situations where a constructor is calling a method which can be overriden by a subclass. This is a potentially dangerous situation because the overriden method might now depend on fields in the subclass which are not yet initialized because the superclass constructor isn't finished.

I don't understand why the warning is triggering when a class calls a final method which is declared in one of it's own parents.

Here's an example:

package .example;

public class A {
    public final int getNumber() {
        return 10;
    }
}

public class B extends A {
    public B(){
        getNumber(); // Compiler warns here:
                     // warning: [this-escape] possible 'this' escape 
                     // before subclass is fully initialized
    }
}

Is there a way that B can be extended which would cause a problem? If getNumber() was not final then a subclass of B could potentially break itself, but I don't see the error condition here.

A potential problem is if the superclass method calls another non-final method. Assuming that that not the case, is there still an error condition?

I can't tell if this warning is a false positive, or a very esoteric error I don't understand.

• java
• compiler-warnings
• java-21

• 8 The final method could very well call another, non-final method. – Sweeper Commented Jan 17 at 19:58
• 7 Who says you have access to the implementation of the super class to recursively check when doing that compilation? Analyses within the same file are the only kind you can guarantee doing. – Louis Wasserman Commented Jan 17 at 20:55
• 1 You have access to the compiled version, but is that necessarily enough? – Louis Wasserman Commented Jan 17 at 22:21
• 4 According to the pull request (github/openjdk/jdk/pull/11874): Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. For me this seems to imply that the compiler only notices that you call a super class method. Since it doesn't look outside the current source it doesn't recognize that the method is final and doesn't do any unsafe operations. – Thomas Kläger Commented Jan 18 at 9:09
• 4 @LouisWasserman You have access to the compiled version, But that can later be changed without our own code needing to be recompiled. – Anonymous Commented Jan 18 at 10:34

1 Answer 1

As pointed out in the comments, it has been specified

Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up.

The reason is, as also mentioned in the comments, if A is not part of the compilation unit, it could be changed and recompiled independently, so that getNumber()’s implementation calls overridable methods at runtime.

There is not even a guaranty that getNumber() will be final at runtime. As the specification says:

Changing a method that is declared final to no longer be declared final does not break compatibility with pre-existing binaries.

Even the opposite applies, as long as there is no method actually overriding the method then turned into final. Or, in other words, for method invocations, it doesn’t matter whether the target method is final or not.