ECJ Relevant JDK Issues

Collection of bugs in the OpenJDK bug tracker that are affecting compatibility between ecj - JLS - javac.

Wildcards and captures

Here my understanding is: JLS is "more correct" (in terms of type theory) than javac, but Oracle prefers not to change javac in "breaking" ways. I seem to recall several examples where even JDK libraries would need to be changed to be accepted by a corrected compiler.

• Widening of capture vars occurs at unspecified times
  • https://bugs.openjdk.org/browse/JDK-8016207 (since 2013)
• Inference: define supertype parameterization for wildcard-parameterized types
  • https://bugs.openjdk.org/browse/JDK-8016196 (since 2013)
  • used as an excuse for a test from #4315
• 18.4: Clean up resolution of capture ivars
  • https://bugs.openjdk.org/browse/JDK-8054721 (since 2014)
  • Improved in ecj via https://github.com/eclipse-jdt/eclipse.jdt.core/pull/4735
  • See InferenceContext18.SHOULD_WORKAROUND_BUG_JDK_8054721
• skip capture conversion before subtyping if types are parameterizations of the same class or interface
  • https://bugs.openjdk.org/browse/JDK-8160244 (since 2016)
• Incorrect treatment of wildcards in subtyping
  • https://bugs.openjdk.org/browse/JDK-8164401 (since 2016) ❌ javac accepts, throws at runtime ✔️ ecj rejects
• type inference: javac is incorrectly applying capture conversion during incorporation
  • https://bugs.openjdk.org/browse/JDK-8206142 (since 2018) ❌ javac rejects ✔️ ecj accepts
• skip capture conversion before subtyping if types are parameterizations of the same class or interface
  • https://bugs.openjdk.org/browse/JDK-8160244 (since 2016) ❌ javac rejects ✔️ ecj accepts

With examples where ecj and javac are congruent:

• 18.2.1: Capture variables should not escape lambda bodies
  • https://bugs.openjdk.org/browse/JDK-8170887 (since 2016)
• Lower bound containing wildcard get lost during type inference
  • https://bugs.openjdk.org/browse/JDK-8251891 (since 2020)

Unchecked conversion / handling of raw types / erasure

• https://bugs.openjdk.java.net/browse/JDK-8026527 (since 2013)
  • See InferenceContext18.SIMULATE_BUG_JDK_8026527
• https://bugs.openjdk.org/browse/JDK-6791481 (since 2009)

Intersection types

In this category we might be dealing with some issues that don't have a ready, consistent answer in type theory.

• 4.9: Clarify membership of intersection types for wildcard parameterizations
  • https://bugs.openjdk.org/browse/JDK-7034922 (since 2011)
• GLB ignores different parameterizations of the same type
  • https://bugs.openjdk.org/browse/JDK-8043374 (since 2014) both compilers questionable - in different ways
• see https://bugs.eclipse.org/bugs/show_bug.cgi?id=521212#c4

Sub-optimal inference of standalone expressions

In this category type inference may produce a result sufficient for a standalone expression, but when the resolved type is used downstream, a "smarter" result may be desired. Think if a.m(b).c(d): a sub-optimal (but correct!) result of inferring a.m(b) may case inference for c(d) to fail.

• See https://mail.openjdk.org/pipermail/compiler-dev/2026-January/032540.html
• https://github.com/eclipse-jdt/eclipse.jdt.core/issues/4731

Unspecified details of communication between inner and outer inference

In this category we have issues, that at a first glance might appear as implementation details not relevant for a specification, but since type inference is specified as an algorithm rather than in a declarative style, every aspect of that algorithm is relevant.

• See https://bugs.eclipse.org/bugs/show_bug.cgi?id=499725#c6
• See https://bugs.eclipse.org/bugs/show_bug.cgi?id=508834#c4
• See https://bugs.eclipse.org/bugs/show_bug.cgi?id=548589#c4
• "Inference: stuck expressions should not be considered ahead of target-type constraints evaluation"
  • https://bugs.openjdk.org/browse/JDK-8153748 (since 2016)
  • See InferenceContext18.SHOULD_WORKAROUND_BUG_JDK_8153748
• See our speculative distinction in BoundSet regarding captures vs allCaptures
• See the protocol in InferenceContext18 of enterPolyInvocation() + resumeSuspendedInference() - largely our (necessary) invention