Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 207959

Summary:	[1.5][compiler] secondary error upon broken parameter type
Product:	[Eclipse Project] JDT	Reporter:	Maxime Daniel <maxime_daniel>
Component:	Core	Assignee:	Philipe Mulet <philippe_mulet>
Status:	VERIFIED INVALID	QA Contact:
Severity:	normal
Priority:	P3	CC:	philippe_mulet
Version:	3.4
Target Milestone:	3.4 M4
Hardware:	PC
OS:	All
Whiteboard:

Description Maxime Daniel

2007-10-30 08:13:07 EDT

Build id: I20071029-0010 (aka current candidate for 3.4 M3)

In the aftermath of bug 204536, it occurred to me that in the following test case (which is GenericTypeTest#1184), we could do better in terms of resilience:

public class X<T extends Zork & Runnable> {
  T get() { return null; }
  void foo(X x) {
    Runnable r = x.get(); // extra error here
  }
}

More specifically, while x.get returns something of a broken type (Zork being undefined), that broken type still extends Runnable, and the assignment to r should be considered as legit.

Comment 1 Philipe Mulet

2007-12-03 12:36:42 EST

Actually, the problem comes from using a raw type X.

Following works as expected:
public class X<T extends Zork & Runnable> {
  T get() { return null; }
  void foo(X<T> x) {
    Runnable r = x.get();
  }  
}

Closing as invalid.
Added GenericTypeTest#test1222

Comment 2 Maxime Daniel

2007-12-04 04:40:53 EST

In fact, we do better than javac 7 on the second case.

Comment 3 Kent Johnson

2007-12-11 12:01:36 EST

Verified for 3.4M4 using build I20071210-1800.