Bug 297656 - Map.entrySet cannot assign to var Set<Entry<?,?>
Summary: Map.entrySet cannot assign to var Set<Entry<?,?>
Status: VERIFIED INVALID
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.6   Edit
Hardware: PC Windows 7
: P3 normal (vote)
Target Milestone: 3.6 M5   Edit
Assignee: Srikanth Sankaran CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-12-12 05:06 EST by Xiang Qinxian CLA
Modified: 2010-01-25 14:47 EST (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Xiang Qinxian CLA 2009-12-12 05:06:46 EST
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; zh-CN; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5 GTB6
Build Identifier: I20091210-1301

65: public void browseMap(Map<?, ?> map) {
66:	Object key, value;
67:	Set<Entry<?, ?>> entrySet = map.entrySet();
68:	for (Entry<?, ?> entry : map.entrySet()) {
		key = entry.getKey();
		value = entry.getValue();
	}
}
In current version JDT, line 67 will reported a compile error.
Set<?> entrySet = map.entrySet(); 
the above line is jdt auto completed. 
You know, you mouse tip the map.entrySet() is just Set<Entry<?,?>>

Reproducible: Always
Comment 1 Srikanth Sankaran CLA 2009-12-15 01:43:12 EST
(In reply to comment #0)
> User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; zh-CN; rv:1.9.1.5)
> Gecko/20091102 Firefox/3.5.5 GTB6
> Build Identifier: I20091210-1301
> 
> 65: public void browseMap(Map<?, ?> map) {
> 66:    Object key, value;
> 67:    Set<Entry<?, ?>> entrySet = map.entrySet();
> 68:    for (Entry<?, ?> entry : map.entrySet()) {
>         key = entry.getKey();
>         value = entry.getValue();
>     }
> }
> In current version JDT, line 67 will reported a compile error.

Hello,

I don't see a bug here at all.

(a) That JDT reports an error in line 67 above is correct and
as it should be. The type of RHS is Set<Entry<?, ?>> and while
the type of LHS is also Set<Entry<?, ?>> and so are seemingly
compatible, in reality they are not. The compiler cannot
guarantee that the "same" unknown type figures on each side. So
it has to reject this construct as type mismatch. As a matter of
fact each of the 4 ?s that feature in the line must be treated
as a distinct unknown type ("capture of the wildcard ?") 
 
> Set<?> entrySet = map.entrySet(); 
> the above line is jdt auto completed.

(b) This is again correct and see that this line compiles
alright.

> You know, you mouse tip the map.entrySet() is just Set<Entry<?,?>>

(c) Again, this is correct. It is just that type safety demands
that each of unknown types has to be treated as distinct and so
an expression of type Set<Entry<?,?>> is not to be treated as
assignment compatible to another of type Set<Entry<?,?>>.

If I have misunderstood what you are reporting, please reopen
this defect.
Comment 2 Xiang Qinxian CLA 2009-12-15 02:18:17 EST
Yes, Your right. At this, I do mismake from any one point.

Though, from the whole, it do be a bug. Who's? God know!
In another word: From another aspect, the spec do mismake.
the LHS wildcard not equal the RHS wildcard.
LHS just do waiting, wait for the RHS, you give what, I accept what.

From the point, I do mismake again, the language not context sensitive, just context-related language.

BTW,another aspect again, the same spec, different result.
for some generic code, sun javac and eclipse jdt do not do same compilation result.
Comment 3 Srikanth Sankaran CLA 2009-12-15 03:17:59 EST
(In reply to comment #2)

> BTW,another aspect again, the same spec, different result.
> for some generic code, sun javac and eclipse jdt do not do same compilation
> result.

We would be interested in hearing of such cases. Please raise separate defects
with code examples that show differences in behavior between javac and eclipse.
Thanks!
Comment 4 Xiang Qinxian CLA 2009-12-15 07:02:03 EST
(In reply to comment #3)
> (In reply to comment #2)
> 
> > BTW,another aspect again, the same spec, different result.
> > for some generic code, sun javac and eclipse jdt do not do same compilation
> > result.
> 
> We would be interested in hearing of such cases. Please raise separate defects
> with code examples that show differences in behavior between javac and eclipse.
> Thanks!
A before stronger memory, is guice 1.0, 
which code works eclipse fine, but sun java6 not work, report a visitor, the guys say sun java1.5 works.

the latest is a java method generic.a very simple example:
public class Test3 {
	<T> T service() {
		return service2();
	}

	<T> T service2() {
		return null;
	}
}

I tested at sun java6 java version "1.6.0_16" and sun java7 ava(TM) SE Runtime Environment (build 1.7.0-ea-b77), both compile error.
Test3.java:4: 缺少方法主体,或声明抽象
<T>T service();
     ^
1 错误

BTW, in my memory, eclipse jdt generic constraint seems looser than sun javac, some code sun javac not works but eclipse jdt works fine, so not care sun javac, hear eclipse, just fine so.
Comment 5 Xiang Qinxian CLA 2009-12-15 07:10:21 EST
(In reply to comment #4)
> (In reply to comment #3)
> > (In reply to comment #2)
> > 
> > > BTW,another aspect again, the same spec, different result.
> > > for some generic code, sun javac and eclipse jdt do not do same compilation
> > > result.
> > 
> > We would be interested in hearing of such cases. Please raise separate defects
> > with code examples that show differences in behavior between javac and eclipse.
> > Thanks!
> A before stronger memory, is guice 1.0, 
> which code works eclipse fine, but sun java6 not work, report a visitor, the
> guys say sun java1.5 works.
> 
> the latest is a java method generic.a very simple example:
> public class Test3 {
>     <T> T service() {
>         return service2();
>     }
> 
>     <T> T service2() {
>         return null;
>     }
> }
> 
> I tested at sun java6 java version "1.6.0_16" and sun java7 ava(TM) SE Runtime
> Environment (build 1.7.0-ea-b77), both compile error.
> Test3.java:4: 缺少方法主体,或声明抽象
> <T>T service();
>      ^
> 1 错误
> 



SORRY, the telephone bother me. so bother you.:)
the javac error should be:
Test3.java:4: 无法确定 <T>T 的类型参数;对于上限为 T,java.lang.Object 的类型变量 T,不存在唯一最大实
例
                return service2();
                               ^
1 错误
It's type variable bound error.
Comment 6 Srikanth Sankaran CLA 2009-12-16 00:19:34 EST
(In reply to comment #4)
> (In reply to comment #3)
> > (In reply to comment #2)
> > 
[...]

> > Thanks!
> A before stronger memory, is guice 1.0, 
> which code works eclipse fine, but sun java6 not work, report a visitor, the
> guys say sun java1.5 works.
> the latest is a java method generic.a very simple example:
> public class Test3 {
>     <T> T service() {
>         return service2();
>     }
>     <T> T service2() {
>         return null;
>     }
> }
> I tested at sun java6 java version "1.6.0_16" and sun java7 ava(TM) SE Runtime
> Environment (build 1.7.0-ea-b77), both compile error.
> Test3.java:4: 缺少方法主体,或声明抽象
> <T>T service();

For the record, this piece of code compiles fine with eclipse as well as
1.7 b77.
Comment 7 Xiang Qinxian CLA 2009-12-16 01:44:03 EST
(In reply to comment #6)
> (In reply to comment #4)
> > (In reply to comment #3)
> > > (In reply to comment #2)
> > > 
> [...]
> 
> > > Thanks!
> > A before stronger memory, is guice 1.0, 
> > which code works eclipse fine, but sun java6 not work, report a visitor, the
> > guys say sun java1.5 works.
> > the latest is a java method generic.a very simple example:
> > public class Test3 {
> >     <T> T service() {
> >         return service2();
> >     }
> >     <T> T service2() {
> >         return null;
> >     }
> > }
> > I tested at sun java6 java version "1.6.0_16" and sun java7 ava(TM) SE Runtime
> > Environment (build 1.7.0-ea-b77), both compile error.
> > Test3.java:4: 缺少方法主体,或声明抽象
> > <T>T service();
> 
> For the record, this piece of code compiles fine with eclipse as well as
> 1.7 b77.
Yes, Sorry again.that phone:)

As to lhs unknown type and rhs unkown type, IMO, the spec should unified.
My reason as follows:
List<?> getList(){return Collections.EMPTY_LIST;}
Class<?> getClass(String className){return null;}

Constructor<?> constructor=clas.getConstructor();
List<?> list = getList();
Class<?> clas = getClass(className);
Constructor<?>[] constructors=clas.getConstructors();

Through the generic array have a little difference.
Above case indicate one point: 
lhs wildcard should accept any type.
It different from the write operation.
Just like that I say before: 
the lhs unknown type, can be understand as,
you give me what, I acept what.:)

BTW, as before talk, unknown!=unknown; so jdt quick fix for "Set<Entry<?,?> set=map.entrySet();" line just be Set<Entry<,>, should be another bug.
I not known jdt project management, If am I, I will change the spec, to just let line compiled ok:)
Comment 8 Olivier Thomann CLA 2010-01-25 14:47:28 EST
Verified for 3.6M5 using I20100125-0800