Regression in Eclipse 2025-12: Type mismatch even for variables with the exact same type.

[niks]

The following use case worked for all previous releases and compiles fine with javac:

package eclipsebug;
public class EclipseBug {

  void error1() {
    var someObject = getObject(); // <<--- Compiler complains here
  }

  void error2() {
    SomeObject<? extends SomeType<?, ? extends SpecialLocation>, ? extends SpecialLocation, ?> theObject;
    method(theObject); // <<--- Compiler complains here
  }

  void error3() {
    SomeObject<? extends SomeType<?, ? extends SpecialLocation>, ? extends SpecialLocation, ?> theObject;
    SomeObject<? extends SomeType<?, ? extends SpecialLocation>, ? extends SpecialLocation, ?> theObject2 = theObject; // <<--- Compiler complains here
  }

  void method(SomeObject<? extends SomeType<?, ? extends SpecialLocation>, ? extends SpecialLocation, ?> theObject) {
  }

  private SomeObject<? extends SomeType<?, ? extends SpecialLocation>, ? extends SpecialLocation, ?> getObject() {
    return null;
  }

  static interface SomeLocation {
  }

  static interface SpecialLocation extends SomeLocation {
  }

  static interface SomeType<O extends SomeObject<? extends SomeType<?, L>, L, ? extends SomeObject<?, ?, ?>>, L extends SomeLocation> {
  }

  public interface SomeObject<T extends SomeType<?, L>, L extends SomeLocation, P extends SomeObject<?, ?, ?>> {
  }
}

This code compiles fine with javac and Eclipse 2025-09.
But it fails with 2025-12 (4.38.0). The compiler complains with the following errors.

In error1 the error message is:

Type mismatch: cannot convert from EclipseBug.SomeObject<capture#1-of ? extends EclipseBug.SomeType<?,? extends EclipseBug.SpecialLocation>,capture#2-of ? extends EclipseBug.SpecialLocation,capture#3-of ?> to EclipseBug.SomeObject<? extends EclipseBug.SomeType<?,? extends EclipseBug.SpecialLocation> & EclipseBug.SomeType<?,? extends EclipseBug.SpecialLocation>,? extends EclipseBug.SpecialLocation,?>

As the return type of getObject() is fully specified the compiler should infer that type and assign it to the variable declared as var without any issue.

In error2 the error message is:

The method method(EclipseBug.SomeObject<? extends EclipseBug.SomeType<?,? extends EclipseBug.SpecialLocation>,? extends EclipseBug.SpecialLocation,?>) in the type EclipseBug is not applicable for the arguments (EclipseBug.SomeObject<capture#6-of ? extends EclipseBug.SomeType<?,? extends EclipseBug.SpecialLocation>,capture#7-of ? extends EclipseBug.SpecialLocation,capture#8-of ?>)

The parameter of the method has the exact same type as the local variable, so it should be applicable to call the method.

In error3 the error message is:

Type mismatch: cannot convert from EclipseBug.SomeObject<capture#11-of ? extends EclipseBug.SomeType<?,? extends EclipseBug.SpecialLocation>,capture#12-of ? extends EclipseBug.SpecialLocation,capture#13-of ?> to EclipseBug.SomeObject<? extends EclipseBug.SomeType<?,? extends EclipseBug.SpecialLocation>,? extends EclipseBug.SpecialLocation,?>

Here the compiler complains about assigning a value of one local variable to the other local variable, even though the two local variables are declared with the exact same type.

This issue will bock us from upgrading Eclipse until it is fixed.
@stephan-herrmann could you please look into this? It might be related to #4635

Best Regards
Michael

[srikanth-sankaran]

This issue will bock us from upgrading Eclipse until it is fixed.
@stephan-herrmann could you please look into this? It might be related to #4635

Thanks for the defect report. Stephan is away for a few days and will investigate this upon his return.

[niks]

I was able to further reduce the complexity of the example to the following code, which still complains at the same locations with the corresponding error messages. There are now only two generic parameters on SomeObject left.

package eclipsebug;

public class EclipseBug {

  void error1() {
    var someObject = getObject(); // <<--- Compiler complains here
  }

  void error2() {
    SomeObject<? extends SomeType<? extends SpecialLocation>, ? extends SpecialLocation> theObject;
    method(theObject); // <<--- Compiler complains here
  }

  void error3() {
    SomeObject<? extends SomeType<? extends SpecialLocation>, ? extends SpecialLocation> theObject;
    SomeObject<? extends SomeType<? extends SpecialLocation>, ? extends SpecialLocation> theObject2 = theObject; // <<--- Compiler complains here
  }

  void method(SomeObject<? extends SomeType<? extends SpecialLocation>, ? extends SpecialLocation> theObject) {
  }

  private SomeObject<? extends SomeType<? extends SpecialLocation>, ? extends SpecialLocation> getObject() {
    return null;
  }

  static interface SomeLocation {
  }

  static interface SpecialLocation extends SomeLocation {
  }

  static interface SomeType<L extends SomeLocation> {
  }

  public interface SomeObject<T extends SomeType<L>, L extends SomeLocation> {
  }
}

[niks]

We have a second use case and I was able to burn it down to a small example. As I assume it is related to the same issue, I report it as a comment here. I post the full example file again, even though only the new error4 use case at the bottom is new.

package eclipsebug;

public class EclipseBug {

  void error1() {
    var someObject = getObject(); // <<--- Compiler complains here
  }

  void error2() {
    SomeObject<? extends SomeType<? extends SpecialLocation>, ? extends SpecialLocation> theObject;
    method(theObject); // <<--- Compiler complains here
  }

  void error3() {
    SomeObject<? extends SomeType<? extends SpecialLocation>, ? extends SpecialLocation> theObject;
    SomeObject<? extends SomeType<? extends SpecialLocation>, ? extends SpecialLocation> theObject2 = theObject; // <<--- Compiler complains here
  }

  void method(SomeObject<? extends SomeType<? extends SpecialLocation>, ? extends SpecialLocation> theObject) {
  }

  private SomeObject<? extends SomeType<? extends SpecialLocation>, ? extends SpecialLocation> getObject() {
    return null;
  }

  static interface SomeLocation {
  }

  static interface SpecialLocation extends SomeLocation {
  }

  static interface SomeType<L extends SomeLocation> {
  }

  static interface SomeObject<T extends SomeType<L>, L extends SomeLocation> {
  }

  // Second use case - unable to assign the inferred type

  void error4() {
    var o2 = getObject2();
    var o = getAnotherObject(o2); // <<-- Compiler complains here
  }

  private SomeObject<?, ? extends SpecialLocation> getObject2() {
    return null;
  }

  interface AnotherObject<E extends SomeObject<?, ?>> {
  }

  public <E extends SomeObject<?, ?>> AnotherObject<E> getAnotherObject(E source) {
    return null;
  }
}

In error4 the compiler complains with the following error message:

Type mismatch: cannot convert from EclipseBug.AnotherObject<EclipseBug.SomeObject<capture#12-of ? extends EclipseBug.SomeType<? extends EclipseBug.SpecialLocation>,capture#13-of ? extends EclipseBug.SpecialLocation>> to EclipseBug.AnotherObject<? extends EclipseBug.SomeObject<? extends EclipseBug.SomeType<? extends EclipseBug.SpecialLocation> & EclipseBug.SomeType<? extends EclipseBug.SpecialLocation>,? extends EclipseBug.SpecialLocation>>

Note that getObject2 differs from getObject in that it only specifies an upper bound for the second generic parameter. Assigning it to var o2 is OK for the compiler. (Compared to assigning getObject() to var someObject in error1, which fails.)

[stephan-herrmann]

@stephan-herrmann could you please look into this? It might be related to #4635

The relation to #4635 looks like an good educated guess. Unfortunately this implies that I cannot make any guarantees for a timely fix, as this may require us to solve problems that are still unresolved in JLS for more than a decade.

[niks]

Unfortunately this implies that I cannot make any guarantees for a timely fix, as this may require us to solve problems that are still unresolved in JLS for more than a decade.

That is very unfortunate. You mean that the JLS may also imply that other compilers are wrong? Which part of the JLS do you mean? Is there some public discussion about that topic?

All previous Eclipse compiler up to 2025-09 were happy with the code, so I was assuming that this is a regression...

Furthermore, I don't understand what could be unclear, especially for case error1, where the return type of a method is assigned to a local variable declared using local type inference... (Just from a developers point of view: the inferred type should be exactly the return type of the method...)

[stephan-herrmann]

You mean that the JLS may also imply that other compilers are wrong?

Generally, the interaction of type inference and wildcard capture is weakly specified in JLS, and javac developers decided to do various unspecified things to be "smarter". OTOH, the case error2() does not involve type inference, so perhaps analyzing that case will give a useful hint about a possible bug in ECJ.