Bug ID: JDK-6650759 Inference of formal type parameter (unused in formal parameters) is not performed

JDK-6650759 : Inference of formal type parameter (unused in formal parameters) is not performed

Type: Enhancement
Component: tools
Sub-Component: javac
Affected Version: 7

Priority: P3
Status: Closed
Resolution: Fixed
OS: generic,linux
CPU: generic,x86

Submitted: 2008-01-15
Updated: 2017-05-16
Resolved: 2012-01-13

Versions (Unresolved/Resolved/Fixed)

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 b72Fixed	OpenJDK6Fixed

Related Reports

Duplicate :	JDK-6862521 - closed/javax/swing/JTable/sorting/UnitTest.java test fails with invalid inferred types.
Relates :	JDK-6369608 - inference: Inferred types not substituted in bounds of unconstrained type variables
Relates :	JDK-6707034 - javac accepts method invocation with actuals that are not subtypes of the formal
Relates :	JDK-6569074 - Type inference fails with bounded type parameters
Relates :	JDK-6278587 - Compiler fails to infer correct type for under-constrained type variables
Relates :	JDK-6640435 - inference: propagate >> and == constraints to help uninferred type vars
Relates :	JDK-7086586 - Inference producing null type argument
Relates :	JDK-6811943 - inference: javac 1.6 & Eclipse infer more types than JLS (umbrella CR)
Relates :	JDK-6638712 - Inference with wildcard types causes selection of inapplicable method
Relates :	JDK-6785112 - Umbrella: issues with generic method type-inference
Relates :	JDK-7034548 - Statement with generics fails to compile in one line, compiles in two lines

Description

This source code:
-----------------------------------------------------------------------------
public class GenericTest {
    
    public static interface Interface<T> { }
    public static class IntegerInterface implements Interface<Integer> { }
    
    public static <I extends Interface<T>, T> T getGenericValue(I test) {
        return null;
    }
    
    public static void testSet(Integer test) { }
    
    public static void main(String args[]) {
        
        Integer test = getGenericValue(new IntegerInterface());
        testSet(getGenericValue(new IntegerInterface()));  //flagged as an error
    }
}
---------------------------------------------------------------------------------------

Produces the following compilation error:
---------------------------------------------------------------------------------------
GenericTest.java:15: testSet(java.lang.Integer) in GenericTest cannot be applied to (java.lang.Object)
         testSet(getGenericValue(new IntegerInterface()));  //flagged as an error
         ^
1 error
---------------------------------------------------------------------------------------

On:
java version "1.7.0-ea"
Java(TM) SE Runtime Environment (build 1.7.0-ea-b22)
Java HotSpot(TM) Server VM (build 11.0-b08, mixed mode)

But not on:
java version "1.6.0_05-ea"
Java(TM) SE Runtime Environment (build 1.6.0_05-ea-b04)
Java HotSpot(TM) Tiered VM (build 1.6.0_05-ea-b04, mixed mode)

Comments

SUGGESTED FIX A webrev of this fix is available at the following URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/dda7e13f09fb

07-09-2009

EVALUATION Update: this bug has been caused by 6278587 - the bug is not present in JDK6/5. As such it should be regarded as a regression (as it was suggested by the last three lines of 'descriptions' - the submitter itself suggested that this code used to work with elder compilers). See also 6811943, a JLS RFE that summarizes the difference between javac's and JLS.

03-03-2009

EVALUATION This situatioin can be regarded as a consequence of the interplay between the JLS bug described in 6640435 and a limitation of section 15.12.2.8 of the JLS. Here, a constraint of the kind T == Integer is found during the first step of type inference (the one taking into account actual vs. formal parameter types - JLS 15.12.2.7). However, since this constraint does NOT involve the type variable I being inferred, this constraint is simply discarded by javac. During the second step of type inference (the one taking into account return type along with uninferred type variables' bounds) start from scatch. Moreover, since the the return type in the second call to the method getGenericValue() is not subject to an assigment conversion, no further constraints on T is derived in 15.12.2.8. The only constraint is thus Object >> Integer (being Object the bound of T), so that the inferred type of T is indeed glb(Object) = Object. This choice is not compliant with the signature of the method testSet, thus triggering the error. Resuming, there are two possible solutions to this bug: 1) Propagate the constraint T==Integer from 15.12.2.7 to 15.12.2.8 2) Generalizing 15.12.2.8 in order to infer a constraint S >> T if the type variable T appear in return-type position of a generic method m1() whose evaluation is passed to another method m2() accepting an argument of type S.

11-02-2008