JDK-8048547 : JLS8 9.9: non-wildcard parameterization succeeds unexpectedly
  • Type: Bug
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 8,9
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2014-06-27
  • Updated: 2024-01-11
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.
Other
tbd_majorUnresolved
Related Reports
Blocks :  
Blocks :  
Duplicate :  
Description
Let's consider following code:

public class Test13 {
    interface Iface<A1, A2 extends A1> {
        String m(A1 t);
    }

    static void m(Iface<? super Number, ? super Integer> i) {
    }

    public static void run() {
        m((Number a) -> a.toString());
    }
}

It compiles successfully.

While according to 18.5.3:
1. Just one constraint Number=A1 is created causing only A1 to be instantiated in jls-18.5.3-210.

2. A2 is left unchanged as "? super Integer" as it's specified by jls-18.5.3-220-B. So jls-18.5.3-220 finally should yield Iface<Number, ? super Integer>. 

3. According to jls-18.5.3-230 since second type argument contains wildcard, non-wildcard parameterization should be the resulted parameterization.

4. But the non-wildcard parameterization should fail according to jls-9.9-200-C.1-B because second type argument is a wildcard and corresponding type parameter is bound by type parameter (A2 extends A1). 

5. So finally the compilation should fail while actually it succeeds.

It looks like resolution takes place along with reduction in jls-18.5.3-210 in javac.

Comments
The last Dan's comment to JDK-8145614 mentions that the spec is unlikely to be changed. What will be the fate of this bug then?
11-01-2024

The fix for this bug has to wait till JDK-8048543 is fixed
18-06-2016

ILW: Impact = High (doesn't follow spec) Likelihood = Low (unusual use case) Workaround = Low (nothing to do -- program compiles even though strict enforcement would prohibit it) HLL --> P4
05-08-2015

I agree with the evaluation's reading of the spec: program should not compile. Notably, this is true regardless of the lambda body: the error occurs before the lambda body is checked.
05-08-2015

These tests fail on JDK9b28 as well, for this reason tck-red-9 label is added; priority is raised to P2 accordingly. Report: http://baloo.ru.oracle.com/jenkins/job/nightly_compiler_solaris_jck9/21//artifact/java-test-work/jtReport/html/kfl_newfailures.html
11-09-2014

The priority has been raised from P4 to P3 because it's a conformance issues.
09-09-2014

Following tests fail on JDK8b132 (JCK8a) because of this issue: lang/INFR/infr065/infr06502m006/infr06502m006.html lang/INFR/infr065/infr06502m007/infr06502m007.html lang/INFR/infr065/infr06502m008/infr06502m008.html lang/INFR/infr065/infr06502m016/infr06502m016.html lang/INFR/infr065/infr06502m026/infr06502m026.html lang/INFR/infr065/infr06502m027/infr06502m027.html lang/INFR/infr065/infr06502m106/infr06502m106.html lang/INFR/infr065/infr06502m107/infr06502m107.html lang/INFR/infr065/infr06502m108/infr06502m108.html lang/INFR/infr065/infr06502m116/infr06502m116.html lang/INFR/infr065/infr06502m126/infr06502m126.html lang/INFR/infr065/infr06502m127/infr06502m127.html
15-08-2014