Bug 280054 - [1.5][compiler] JDT behavior differs from E34 and javac in generic method
Summary: [1.5][compiler] JDT behavior differs from E34 and javac in generic method
Status: CLOSED DUPLICATE of bug 277643
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.5   Edit
Hardware: PC Windows Vista
: P3 normal (vote)
Target Milestone: 3.5 RC4   Edit
Assignee: Kent Johnson CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-06-12 05:27 EDT by Stepan Mik CLA
Modified: 2009-06-19 03:44 EDT (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 Stepan Mik CLA 2009-06-12 05:27:23 EDT
Build ID: I20090605-1444

Steps To Reproduce:
1. Create compilation unit with provided content
2. Error should appear in B.method2() at line 26



More information:
In earlier version of Eclipse (3.4.2) compiler reported only wanrnings at given line:
  * Type safety: The expression of type X.B needs unchecked conversion to conform to X.B<V>
  * Type safety: Unchecked invocation get(Class<V>, Class<X.B>) of the generic method get(Class<V>, Class<S>) of type X.L
In Eclipse 3.5RC4 this warning changed to error:
  * Type mismatch: cannot convert from X.A to X.B<V>	

I'm not exactly sure which behavior is correct, but I strongly believe that the error report is wrong because return type of B.get may be determined by method arguments.
Such belief is supported by earlier version of JDT and also by Sun JDK 1.6.0_14 javac compiler which also reports only wanings.

Source code:

public class X {

	static class A<V> {
		L l;
		
		public Class<V> vtype() {
			return null;
		}

		public A<V> method1() {
			return l.get(vtype(), B.class);
		}
	}
	
	static class L {
		public <V,S extends A<V>> S get(Class<V> vtype, Class<S> stype) {
			return null;
		}
	}
	
	static class B<V> extends A<V> {
		
		public B<V> method2() {
			return l.get(vtype(), B.class);
		}
	}
}
Comment 1 Kent Johnson CLA 2009-06-12 14:26:05 EDT

*** This bug has been marked as a duplicate of bug 277643 ***
Comment 2 Olivier Thomann CLA 2009-06-12 14:39:17 EDT
Verified using I20090609-1400.
Comment 3 Stepan Mik CLA 2009-06-19 03:44:20 EDT
OK