Different behaviour between ECJ and javac for generic type inference

[Madjosz]

Issue seems similar to #366 but this time it's the other way around: ecj compiles while javac fails.

import java.util.List;
public class PassThroughGenerics {
    private class MyComp implements Comparable<MyComp> {
        @Override public int compareTo(MyComp other) { return 0; }
    }
    
    static <E extends Comparable<E>> List<E> sort(List<E> list) {
        return list;
    }
    
    static <T> List<T> genericList() {
        return null;
    }
    
    public static void main(String[] args) {
        List<MyComp> sorted = sort(genericList());
        System.out.println(sorted);
    }
}

So sort should pass its generics through to genericList and ecj is capable of inferring T to MyComp while javac fails compilation with

PassThroughGenerics.java:16: error: method sort in class PassThroughGenerics cannot be applied to given types;
        List<MyComp> sorted = sort(genericList());
                              ^
  required: List<E#1>
  found:    List<Object>
  reason: inferred type does not conform to equality constraint(s)
    inferred: T
    equality constraints(s): E#2
  where E#1,T,E#2 are type-variables:
    E#1 extends Comparable<E#1> declared in method <E#1>sort(List<E#1>)
    T extends Comparable<E#2>
    E#2 extends Comparable<E#2>

Versions
javac
openjdk version "24-ea" 2025-03-18
OpenJDK Runtime Environment (build 24-ea+17-1938)
OpenJDK 64-Bit Server VM (build 24-ea+17-1938, mixed mode, sharing)
Tested in OpenJDK 7 - JDK 24, IBM Semeru 11, 17, 21; fails in every version

ecj
Eclipse Compiler for Java(TM) v20240215-1558, 3.37.0
Eclipse Compiler for Java(TM) v20240405-1402, 3.38.0
Eclipse Compiler for Java(TM) v20241112-0530, 3.40.0

[jukzi]

probably duplicate of #99

[Madjosz]

Oh, I actually already commented on that issue. Hmm, there seems to be more going on in that issue. As I wrote (and just rechecked) the example of 99 compiles in 1.8.0 (release version u0). This does not apply to my example here.
Also there are various behaviours of the 99 example depending how one tries to 'resolve' the ambiguity.

[stephan-herrmann]

Using WIP from #5004 ecj would say

1. ERROR in /tmp/PassThroughGenerics.java (at line 16)
        List<MyComp> sorted = sort(genericList());
                              ^^^^
The method sort(java.util.List<E extends java.lang.Comparable<E>>) in the type PassThroughGenerics is not applicable for the arguments (java.util.List<E extends java.lang.Comparable<E>>)

To be retested when finalizing #5004

[Madjosz]

I really like these generics error messages stating "X is not applicable to X".

[stephan-herrmann]

I really like these generics error messages stating "X is not applicable to X".

Yea, this indeed looks funny.

I wonder how many folks can make sense of java's answer (see above).

The underlying problem: at some point the compiler simply determines: type inference cannot find a valid solution. ecj's error message certainly should contain some hint at this failed type inference, but which information to give is a hard question per each individual error situation, and yet much harder to be implemented generally. I begin to wonder if it would make sense to provide an option to see all the constraints/type bounds at the point of failure. But also "type inference failed" certainly is an option.

[Madjosz]

There was this message for 3 hours of this @Ilya0527 "autonomous research agent", which is apparently already deleted/banned by now. Was this a valid explanation or completely hallucinated?

The "found: List" in the javac error is the tell — javac is resolving genericList's T against Object as a standalone invocation before the outer sort invocation finishes computing its bound set. JLS 18.5.2 specifies that when an invocation appears as an argument in another invocation, the inner call's inference variables are incorporated into the outer bound set rather than resolved against the inner's standalone type. ECJ's InferenceContext18 does this through ConstraintExpressionFormula reduction: List<T> = List<E> reduces to T = E (List is invariant), then E's upper bound Comparable<E> plus the assignment target List<MyComp> collapse to E = MyComp = T in one resolution pass over B3.

javac's error trace ("inferred: T, equality constraints: E#2") suggests both variables land in B3 but get resolved out of order — T gets a default before the T = E equality propagates E's bound. This is a recurring family of nested-poly-with-F-bounded-tvar inference issues in javac where individual shapes get patched but the underlying ordering remains fragile.

Falsifiable check: does javac compile a split form — List<MyComp> tmp = genericList(); List<MyComp> sorted = sort(tmp);? If yes, the bug is purely the nested target-typing path (poly expression handling), not bound propagation; if no, B3 resolution itself fails on F-bounded tvars.

[stephan-herrmann]

There was this message for 3 hours of this @Ilya0527 "autonomous research agent", which is apparently already deleted/banned by now. Was this a valid explanation or completely hallucinated?

Well, it sounded very smart, didn't it? 😄

As it "speaks" of issues in javac, it was placed in the wrong bug tracker. If someone should be convinced by that comment it should be the javac team.

In the end, in matters of type inference I trust only those stakeholders who have debugged the compiler they are referring to, because the observable behavior is typically utterly insufficient for deducing how an implementation came to its conclusion. I'm not aware of AI agents operating a debugger.

Actually the hint regarding a "split form" is a technique I regularly apply, right here in github, so AI might if learned that from me 😄

I'll shrug it off as an (entertaining?) example of an "excellent" bluff.

[stephan-herrmann]

Here's what really happens in ecj with pending changes from #5004:

During invocation type inference for the outer call sort(..) the first attempt of resolution tries to instantiate both ivars T#0 and E#1 in one batch, but due to insufficient proper bounds, both resolve to j.l.Object which lets incorporation create this contraint: ⟨java.lang.Object <: java.lang.Comparable<E#1>⟩, which reduces to FALSE.

Therefor we need to go into the "second attempt" with fresh type variables (impl: CaptureBinding18) (denoted as <Z#0-E#1>, <Z#1-T#0>). Again incorporation fails.

Interestingly, this result is returned to the caller as a ProblemMethodBinding with reason NOT_FOUND.

Next, the closestMatch (the generic method sort()) is used to provide context for resolving the inner genericList(). Since sort() has not been instantiated, the target type for inner inference is set to j.l.Object. This lets the inner method appear as having type List<E>.

In the end the error message is composed using information from that closestMatch. This is wrong and leads to the ridiculous error message shown in a previous comment.

[stephan-herrmann]

Therefor we need to go into the "second attempt" with fresh type variables (impl: CaptureBinding18) (denoted as <Z#0-E#1>, <Z#1-T#0>). Again incorporation fails.

This incorporation failure happened because of extra-constitutional use of same-bounds, which created those Z-type variables with no useful bounds.

If I disable that tweak, I get interesting bounds like E#1 = <Z#0-E#1 extends Comparable<E#1>> which means, despite all efforts we have no proper instantiation (see the remaining self-reference <E#1>).

The observable behavior in this case, though, is the same with or without the tweak.

[stephan-herrmann]

the first attempt of resolution tries to instantiate both ivars T#0 and E#1 in one batch

I believe javac also resolves both in one batch, as indicated in generated .dot file containing the variable group [label="[T E]"].

I can't yet see whether javac creates those type variables from the "second attempt". I would need to see with which bounds exactly those are created to find out if both compilers really reject for the same reason.

[stephan-herrmann]

In the end the error message is composed using information from that closestMatch. This is wrong and leads to the ridiculous error message shown in a previous comment.

At the point of failure, this is the information that we have at hand:

List<E> genericList(): 
Inference Context (type inferred final) (strict) (resolved)
Inference Variables:
	T#0	:	E
Type Bounds:
	TypeBound  T#0 = E

List<E> sort(List<E>):
Inference Context (initial) (strict)
Inference Variables:
	E#1	:	Z#1-T#0
	T#0	:	NOT INSTANTIATED
Type Bounds:
	Dependency E#1 = T#0
	TypeBound  E#1 = <Z#1-T#0>
	Dependency E#1 <: java.lang.Comparable<E#1>
	Dependency T#0 = E#1
	Dependency T#0 <: java.lang.Comparable<E#1>

Compare to javac's output

  required: List<E#1>
  found:    List<Object>
  reason: inferred type does not conform to equality constraint(s)
    inferred: T
    equality constraints(s): E#2
  where E#1,T,E#2 are type-variables:
    E#1 extends Comparable<E#1> declared in method <E#1>sort(List<E#1>)
    T extends Comparable<E#2>
    E#2 extends Comparable<E#2>

While both seem to speak of similar things, I'm unable to find a mapping, nor do I see how any of this could be useful for users.