Bug 83072 - isAssignmentCompatible and generics is inconsistent
Summary: isAssignmentCompatible and generics is inconsistent
Status: RESOLVED WORKSFORME
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.1   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 3.2 M6   Edit
Assignee: Jerome Lanneluc CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-01-18 05:27 EST by Dirk Baeumer CLA
Modified: 2006-03-27 06:56 EST (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dirk Baeumer CLA 2005-01-18 05:27:39 EST
The following two test should be both return true or both return false:

java.util.Collection<E extends java.lang.Object>= 
   java.util.Collection<E extends java.lang.Object>: true

java.util.Collection<E extends java.lang.Object>= 
   java.util.Vector<E extends java.lang.Object>: false
Comment 1 Dirk Baeumer CLA 2005-01-18 05:28:15 EST
From a type model point of view I would prefer false.
Comment 2 Jerome Lanneluc CLA 2005-01-24 12:42:44 EST
I don't understand. You can assign a variable of type java.util.Collection<E> to
another variable of type java.util.Collection<E>.
Comment 3 Dirk Baeumer CLA 2005-01-24 13:49:54 EST
Sorry for not being precise enough:

all type bindings refer to generic type binding (e.g. the one from the
declaration) not to parameterized types.

In declarations (fields, locals, parameters, return types) generic types can't
be used. Only parameterized types can be used here.

All I try to say is that isAssignmentCompatible on generic types seems to be
questionable. But if we support this we should do it for 

java.util.Collection<E>= java.util.Vector<E>

as well. 

I think the problem comes from the fact that the compiler bindings first check
if the bindings are indentical and then return true.
Comment 4 Philipe Mulet CLA 2005-06-10 04:54:47 EDT
Dirk - is this still an issue in latest ? Compatibility rules changed quite a
few times since then. Please reopen if still an issue.
Comment 5 Philipe Mulet CLA 2006-03-27 06:55:58 EST
closing as no information in a long time, and many fixes occurred in this area since then.
Comment 6 Philipe Mulet CLA 2006-03-27 06:56:10 EST
closing