JDK-8147493 : regression when type-checking unchecked method calls
  • Type: Bug
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 9
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2016-01-15
  • Updated: 2017-04-03
  • Resolved: 2016-01-20
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 9
9 b103Fixed
Related Reports
Duplicate :  
Relates :  
Relates :  
Relates :  
Relates :  
Description
The following code stopped working after JDK-8078093:

abstract class Test {
  interface One {}
  interface Two<I extends One> { I get(); }
  interface Three<T> {}
  interface Four<T> {}

  <E extends Two<?>, L extends Three<E>> Four<L> f(Class raw, E destination) {
    return g(raw, destination.get());
  }

  abstract <I extends One, E extends Two<I>, L extends Three<E>> Four<L> g(
      Class<L> labelClass, I destinationId);
}


$ javac Test.java
error: incompatible types: inference variable I has incompatible bounds
    return g(raw, destination.get());
            ^
    equality constraints: CAP#1
    lower bounds: One
  where I,E,L are type-variables:
    I extends One declared in method <I,E,L>g(Class<L>,I)
    E extends Two<I> declared in method <I,E,L>g(Class<L>,I)
    L extends Three<E> declared in method <I,E,L>g(Class<L>,I)
  where CAP#1 is a fresh type-variable:
    CAP#1 extends One from capture of ?
1 error
Comments
The problem seems to be caused by the fact that the code in Attr::checkMethod reuses the same Warner object (a problem that keeps biting us :-() - as the new code shares more state than the previous speculative-based implementation, the compiler ends up resetting the Warner when checking 'destination.get()' so that the compiler loses track of the fact that it had already encountered an unchecked warning during the applicability check of the first argument (Class <: Class<L>) - subsequently, the call is not flagged as unchecked, and a spurious inference error is then thrown.
15-01-2016