Bug 294508 - [1.5][compiler] Eclipse JDT allows assignment of inferred type argument which is out of bounds
Summary: [1.5][compiler] Eclipse JDT allows assignment of inferred type argument which...
Status: VERIFIED NOT_ECLIPSE
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.6   Edit
Hardware: PC Mac OS X - Carbon (unsup.)
: P3 normal (vote)
Target Milestone: 3.6 M4   Edit
Assignee: Srikanth Sankaran CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-11-06 14:41 EST by Rene Groeschke CLA
Modified: 2009-12-08 03:56 EST (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Rene Groeschke CLA 2009-11-06 14:41:16 EST
User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_1; de-de) AppleWebKit/531.9 (KHTML, like Gecko) Version/4.0.3 Safari/531.9
Build Identifier: 20090920-1017

the following code snippet compiles well in eclipse without any complaining, but it shouldn't i guess:

public <T extends Foo> List<T> getFoos(){

        return null;
    }

    public void getFoosCall(){
        List<?> foos = getFoos();
    }

this snippets should not compile. javac throws the following compile error:

Error:Error:line (20)incompatible types; inferred type argument(s) java.lang.Object do not conform to bounds of type variable(s) T
found   : <T>java.util.List<T>
required: java.util.List<?>



Reproducible: Always

Steps to Reproduce:
1. Create a new java project inside within the eclipse IDE

2. create an empty class Foo

3. create the CompilerTest with the following content:
import java.util.List;

public class TestCompiler {

    public <T extends Foo> List<T> getFoos(){

        return null;
    }

    public void getFoosCall(){
        List<?> foos = getFoos();
    }
}
Comment 1 Srikanth Sankaran CLA 2009-11-09 08:54:30 EST
javac7 (b65) compiles it without problems while javac6 and javac5 report
the error cited in comment#0
Comment 2 Olivier Thomann CLA 2009-11-09 09:01:25 EST
javac b75 compiles it fine too.
Comment 3 Olivier Thomann CLA 2009-11-09 09:01:44 EST
I meant javac 7 b75
Comment 4 Srikanth Sankaran CLA 2009-11-10 08:07:42 EST
(In reply to comment #0)
> User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_1; de-de)
> AppleWebKit/531.9 (KHTML, like Gecko) Version/4.0.3 Safari/531.9
> Build Identifier: 20090920-1017
> the following code snippet compiles well in eclipse without any compl aioning,t
> but it shouldn 't i guelss:

Why exactly do you expect this to fail to compile ? Since List<?> is
List of unknown/anything, why should there be an error ?

As an aside, 

(1) javac 5,6,7 compile the following just fine:

import java.util.List;

public class TestCompiler {

    public <T extends Foo> List<T> getFoos(){
        return null;
    }

    public void getFoosCall(){
        List<Foo> foos = getFoos();  // used to be List<?> foos = getFoos();
    }
}
class Foo {}

(2) Also javac 5,6,7 compile this code fine:

import java.util.List;

public class TestCompiler <T extends Foo> {

    public List<T> getFoos(){
        return null;
    }

    public void getFoosCall(){
        List<?> foos = getFoos();
    }
}
class Foo {}
Comment 5 Rene Groeschke CLA 2009-11-10 11:40:57 EST
We discovered this issue while establishing our continuous integration environment writing ant tasks. I didn't realized, that we actual run our builds only on macosx. Since Apple delivers a self written jdk, I think it is a problem/bug of the macos jdk handling this code different to other JDKs. Tomorrow I will verify this issue on a windows machine using a sun jdk.
Comment 6 Srikanth Sankaran CLA 2009-11-11 01:50:47 EST
This is likely a sun bug:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6315770
fixed and released in 7(b48).

Olivier, can I request you to check with 7b47, 7b48 and 7b49 ? 
(JIM doesn't have these, so I am not able to confirm)
Comment 7 Srikanth Sankaran CLA 2009-11-12 06:03:39 EST
I couldn't get hold of b47 and b48, but could test against
b46 and b49. The program fails to compile in b46 and compiles
alright in b49.

Closing this as NOT_ECLIPSE, since this is a javac bug.
Comment 8 Jay Arthanareeswaran CLA 2009-12-08 03:38:54 EST
Verified for 3.6M4