JDK-6569789 : Compiler test lang/TYPE/type153/type15304/type15304.html fails since jdk7 b05
  • Type: Bug
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 7
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2007-06-14
  • Updated: 2012-03-22
  • Resolved: 2009-11-18
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 7 Other
7 b26Fixed OpenJDK6Fixed
Related Reports
Relates :  
JDK-2152442 - Declaration order of interdependent generic types should not matter
Relates :  
JDK-6192945 - Declaration order of interdependent generic types should not matter
Description
JCK            : JCK-COMPILER 6a b14
J2SE           : FAIL - fail JDK 7 b05+, PASS b04, PASS jdk 6u2
Platform[s]    : FAIL - all
switch/Mode    : FAIL - default

The test lang/TYPE/type153/type15304/type15304.html fails since JDK 7 b05 with the message:
type parameters of <W>void cannot be determined; no unique maximal instance exists for type variable W with upper bounds javasoft.sqe.tests.lang.type153.type15304.C,javasoft.sqe.tests.lang.type153.type15304.I,javasoft.sqe.tests.lang.type153.type15304.I1,javasoft.sqe.tests.lang.type153.type15304.I2
        testMethod(ct);
                  ^
1 error


This problem was probably introduced by integrating CR 6192945
Comments
SUGGESTED FIX see http://sa.sfbay.sun.com/projects/langtools_data/7/6569789/
21-12-2007
EVALUATION This bug is due to the way in which javac calculates glb. When javac computes glb(T1, T2 ... Tn), basically the compiler looks for a type Tk, 1<k<n, such that Tk is a subtype of each Ti, 1<i<n. In the example however, we have that W = glb(C, I, I1, I2), so javac looks for a type which is a subtype of both C, I, I1 and I2. Unfortunately among the upper bounds of W there is not such common subtype (the situation will be different with C implementing both I, I1 and I2). So the inference fails and the compiler reports the problem. The JLS state that (5.1.10) "... where the glb(V1, V2 ... ,Vm) is the (intersection) type V1 & V2 ... & Vm. So in this case javac should infer the intersection type C&I&I1&I2 for W. As a general rule, such an intersection type should be created whenever is not possible to find a suitable common subtype among the arguments of glb.
21-12-2007