JDK-8238213: javac emits wrong error when calling an non-static overloaded method from static

Maurizio Cimadamore maurizio.cimadamore at oracle.com
Fri Oct 2 16:47:23 UTC 2020


I agree that seems to be a discrepancy from what the JLS is saying (and, 
I believe even from what earlier javac versions were doing - e.g. prior 
to 8).

I tried this in Java 7 and this returned:

foo.java:3: error: non-static method test(double) cannot be referenced 
from a static context
     test(5.0);
     ^

as expected.

Maurizio

On 02/10/2020 14:50, B. Blaser wrote:
> Hi,
>
> Consider the following example from JDK-8238213:
>
> public class JavacBrokenError {
>    public static void main(String[] args) {
>      test(5.0);
>    }
>
>    void test(double d) {}
>    /* static */ void test(Double d) {}
> }
>
> It seems that javac correctly finds 'test(double)' during the strict
> resolution phase (§15.12.2.2) but doesn't stop with a static error as
> mandated by §15.12.3 and continues with the loose resolution phase
> (§15.12.2.3) which ends up wrongly with the ambiguous error instead.
>
> The following fix addresses this on jdk14u (langtools:tier1 is OK):
>
> diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java
> b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java
> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java
> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java
> @@ -3283,7 +3283,7 @@
>            */
>           final boolean shouldStop(Symbol sym, MethodResolutionPhase phase) {
>               return phase.ordinal() > maxPhase.ordinal() ||
> -                !sym.kind.isResolutionError() || sym.kind == AMBIGUOUS;
> +                !sym.kind.isResolutionError() || sym.kind ==
> AMBIGUOUS || sym.kind == STATICERR;
>           }
>
>           /**
>
> On jdk16, see:
>
> https://github.com/openjdk/jdk/blob/b8966e1f7bfa2408f0e5330ac310526dd5c3cb2d/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java#L3310
>
> What do you think?
>
> Thanks,
> Bernard


More information about the compiler-dev mailing list