Static interface methods excluded from type variable membership

[fbricon]

Initially reported in redhat-developer/vscode-java#4058:

Following is some sample code to replicate the issue:

public class Tester<T extends Thing> {
    public void test() {
        System.out.println("Testing: " + T.getStuff());  // Error is here
    }

    public static void main(String[] args) {
        Tester<OtherThing> tester = new Tester<>();
        tester.test();
    }

}

interface Thing {
    static String getStuff() {
        return "Stuff";
    }
}

class OtherThing implements Thing {
}

With this, I get a build error: The method getStuff() is undefined for the type T Java(67108964)

I reproduced with the latest Eclipse 2025-12 M2 (Build id: 20251024-0159)

[srikanth-sankaran]

I'll take a look

[srikanth-sankaran]

ECJ behavior goes back at least to 4.20 probably to much before than that. I could compile this code with javac 11 onwards. (jdk10 crashes)

[srikanth-sankaran]

4.4 Type Variables

...

The members of a type variable X with bound T & I1 & ... & In are the members of
the intersection type (§4.9) T & I1 & ... & In appearing at the point where the type
variable is declared.

4.9 Intersection Types

An intersection type takes the form T1 & ... & Tn (n > 0), where Ti (1 ≤ i ≤ n) are types.
Intersection types can be derived from type parameter bounds (§4.4) and cast
expressions (§15.16); they also arise in the processes of capture conversion
(§5.1.10) and least upper bound computation (§4.10.4).

...

Every intersection type T1 & ... & Tn induces a notional class or interface for the
purpose of identifying the members of the intersection type,

...

The members of an intersection type are the members of the class or interface it
induces.
It is worth dwelling upon the distinction between intersection types and the bounds of type
variables. Every type variable bound induces an intersection type. This intersection type is
often trivial, consisting of a single type.

[srikanth-sankaran]

See that ECJ has no trouble compiling this:

public class Tester<T extends Thing> {
    public void test() {
        System.out.println("Testing: " + T.getStuff());  // Error is here
    }

    public static void main(String[] args) {
        Tester<OtherThing> tester = new Tester<>();
        tester.test();
    }

}

class Thing {
    static String getStuff() {
        return "Stuff";
    }
}

class OtherThing extends Thing {
}

[srikanth-sankaran]

Problem originates in org.eclipse.jdt.internal.compiler.lookup.MethodBinding.canBeSeenBy(TypeBinding, InvocationSite, Scope)

In this block of code:

	SourceTypeBinding invocationType = scope.enclosingSourceType();
	if (this.declaringClass.isInterface() && isStatic() && !isPrivate()) {
		if ((invocationSite.isTypeAccess() || invocationSite.receiverIsImplicitThis()) && TypeBinding.equalsEquals(receiverType, this.declaringClass))
			return true;
		return false;
	}

we errorneously conclude that at the invocation site the method getStuff cannot be seen.

[srikanth-sankaran]

Actually, further investigation shows that ECJ behavior has been correct all along.

See JLS 9.4.1 Inheritance and Overriding saying categorically An interface does not inherit private or static methods from its superinterfaces

This would mean that ECJ behaviors is correct.

Indeed there has been recently acknowledgment from OpenJDK side that this is a bug in javac.

See

https://mail.openjdk.org/pipermail/compiler-dev/2025-September/031579.html
https://bugs.openjdk.org/browse/JDK-8365676
https://bugs.openjdk.org/browse/JDK-6644562

I'll release a regression test capturing the current (correct behavior) and close this as won't fix.