Bug 249140 - [1.5][compiler] asymmetric errors with covariant inherited methods
Summary: [1.5][compiler] asymmetric errors with covariant inherited methods
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.4.1   Edit
Hardware: Other Linux
: P3 normal (vote)
Target Milestone: 3.4.2   Edit
Assignee: Kent Johnson CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-09-30 11:50 EDT by Stephan Herrmann CLA
Modified: 2009-02-03 13:14 EST (History)
3 users (show)

See Also:

Attachments
Proposed patch with testcase (9.53 KB, patch)
2008-10-02 15:01 EDT, Kent Johnson CLA 		no flags Details | Diff
Proposed patch with testcase for 3.4.2 (2.70 KB, patch)
2008-10-06 15:19 EDT, Kent Johnson CLA 		no flags Details | Diff
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Stephan Herrmann CLA 2008-09-30 11:50:09 EDT 
Build ID: M20080911-1700

Steps To Reproduce:
The following two program variants produce different error
messages, where I would expect similar messages:

Variant A:
  public interface I1 {
	Object m();
  }
  public abstract class C1 {
	public abstract String m();
  }
  public class C2 extends C1 implements I1 { }

=> The type C2 must implement the inherited abstract method C1.m()

Variant B:
  public interface I1 {
	String m();
  }
  public abstract class C1 {
	public abstract Object m();
  }
  public class C2 extends C1 implements I1 { }

=> The return type is incompatible with I1.m(), C1.m()

This difference is funny since both problems can be
mended with the same fix: insert into C2:
  public String m() { return null; }
Comment 1 Kent Johnson CLA 2008-10-02 12:02:33 EDT 
In the first case, the only issue is the missing implementor in C2 of the abstract method C1.m(). The return type of this method must be String which is a subtype of Object from I1.m()


In the second case, we're not comparing the 2 inherited methods properly.

The error in the second case should never be reported, in which case we'll report the same missing implementation error as case 1.


Philippe - we should likely fix this in 3.4.2 - ok ?
Comment 2 Kent Johnson CLA 2008-10-02 15:01:42 EDT 
Created attachment 114126 [details]
Proposed patch with testcase

Includes patch for bug 243820 which touches MethodVerifier15 but hasn't been released yet
Comment 3 Philipe Mulet CLA 2008-10-06 11:47:23 EDT 
Looks good. +1 for 3.4.2.


BTW - is the problem that specific to classes ?
 interface I1 {
        Object m();
  }
  interface I2 {
        String m();
  }
  public class X implements I1, I2 { }

Here we do complain about missing impl for I1.m(), but shouldn't it complain instead about I2.m() ? (since most specific return type).
Note: javac 6 doesn't do better...
Comment 4 Kent Johnson CLA 2008-10-06 14:55:17 EDT 
I agree that we could find the most specific inherited method, but its not a very common case & definitely not something we would need to do for 3.4.2

If you want it, then we should open a new bug for 3.5
Comment 5 Kent Johnson CLA 2008-10-06 15:19:41 EDT 
Created attachment 114348 [details]
Proposed patch with testcase for 3.4.2
Comment 6 Kent Johnson CLA 2008-10-06 16:25:53 EDT 
Fix and test released for 3.4.2
Comment 7 Kent Johnson CLA 2008-10-06 16:35:45 EDT 
Fix and test released for 3.5M3
Comment 8 David Audel CLA 2008-10-28 06:56:16 EDT 
Verified for 3.5M3 using I20081026-2000 build.
Comment 9 Olivier Thomann CLA 2009-02-03 13:14:00 EST 
Verified for 3.4.2 using M20090121-1700 build.