Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 41989 - bug in type constraints [refactoring]
Summary: bug in type constraints [refactoring]
Status: RESOLVED WONTFIX
Alias: None
Product: JDT
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 3.0   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Tobias Widmer CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-08-26 12:08 EDT by Frank Tip CLA
Modified: 2005-03-23 12:43 EST (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Frank Tip CLA 2003-08-26 12:08:36 EDT
If I extract an interface "I" from class "A" in the program below, which
contains method "zip()" but not method "zap()", the resulting program
will contain a compile-error.

The problem is the fact that the methods J.foo(A) and E.foo(A) in the 
example program are related, despite the fact that one does not override
the other. Therefore, the signature of these methods must either be
changed as a group, or they must not be changed at all. In this example,
we cannot change the signature of E.foo(A), so we can also not change
the signature of J.foo(A). 

I think the solution will be to generate additional type constraints
that enforce equality of parameter types and return types for such
methods, similar to the way overridden methods are currently handled.

  -Frank


package typeConstraintBug;

public class TypeConstraintBug {
	public static void main(String[] args){
		J j = new C();
		j.foo(new A());
		System.out.println("done");
	}
}

class A {
	public void zip(){ }
	public void zap(){ }
}

interface J {
	public void foo(A a1);
}
class B implements J {
	public void foo(A a3){
		a3.zip();
	}
}
class E {
	public void foo(A a4){
		a4.zap();
	}
}
class C extends E implements J  {
	/* no foo() here */
}
Comment 1 Frank Tip CLA 2004-12-16 13:25:21 EST
This bug is also causing problems for the new generics-related
refactorings.  We should increase its priority.

  -Frank
Comment 2 Dirk Baeumer CLA 2005-03-21 17:02:38 EST
Tobias, is this still an issue.
Comment 3 Tobias Widmer CLA 2005-03-23 12:43:06 EST
This marriage of convenience setup is the only ripple method case with the new 
typeconstraint infrastructure which does not work. Doing this one right would 
involve building subtype hierarchies with a considerable performance loss.
Closing as wont fix