Generic Method override compatibility [message #199717] |
Tue, 29 March 2005 20:50  |
Eclipse User |
|
|
|
I tried to find references to the problem but couldn't. I face it all the
time and I thought some else must have had the same problem already.
Oh well, here it goes.
With both 3.1M4 and 3.1M5a the following code compiles without any
problems.
public interface MyIface {
public <T> void foo(T p);
}
public class MyClass implements MyIface{
public <T extends Integer> void foo(T p) {
//does something
}
}
However, javac 1.5 gives me:
MyClass.java:1: MyClass is not abstract and does not override abstract
method <T>foo(T) in MyIface
public class MyClass implements MyIface{
^
1 error
It seems that for the eclipse compiler, <T extends Integer> is the same as
<T> in terms of method signature. For the javac compiler these are
different thingss.
Does anyone know if this is a Bug in eclipse or javac, or if this is a
known decision, which is taking both tools in different directions?
BTW It gets more interesting. The code underneath produces the following
output with the eclipse compiler:
Base: 1
Sub: 1
Exception in thread "main" java.lang.ClassCastException: java.lang.String
And this output with javac:
Base: 1
Sub: 1
Exception in thread "main" java.lang.ClassCastException: java.lang.String
This seems to be a consistent and well-thought implementation given these
two simple examples. Does someone else know more details about this issue?
Coconha
public class Signature {
public Signature() {
super();
Sub s = new Sub();
s.foo(new Integer(1));
s.foo("as");
}
public class Base {
public <T> void foo(T a) {
System.out.println("Base: " + a);
}
}
public class Sub extends Base {
public <T extends Integer> void foo(T a) {
super.foo(a);
System.out.println("Sub: " + a);
}
}
public static void main(String[] args) {
new Signature();
}
}
|
|
|
Re: Generic Method override compatibility [message #199739 is a reply to message #199717] |
Wed, 30 March 2005 02:31  |
Eclipse User |
|
|
|
That's a bug in the eclipse compiler. Could you please file it in Bugzilla?
The two methods have different erasures: MyClass#foo(Integer) cannot
implement MyIface#foo(Object).
Thanks,
Markus
coconha wrote:
> I tried to find references to the problem but couldn't. I face it all
> the time and I thought some else must have had the same problem already.
>
> Oh well, here it goes.
>
> With both 3.1M4 and 3.1M5a the following code compiles without any
> problems.
>
> public interface MyIface {
> public <T> void foo(T p);
> }
> public class MyClass implements MyIface{
> public <T extends Integer> void foo(T p) {
> //does something
> }
> }
>
> However, javac 1.5 gives me:
>
> MyClass.java:1: MyClass is not abstract and does not override abstract
> method <T>foo(T) in MyIface
> public class MyClass implements MyIface{
> ^
> 1 error
>
> It seems that for the eclipse compiler, <T extends Integer> is the same
> as <T> in terms of method signature. For the javac compiler these are
> different thingss.
>
> Does anyone know if this is a Bug in eclipse or javac, or if this is a
> known decision, which is taking both tools in different directions?
>
> BTW It gets more interesting. The code underneath produces the following
> output with the eclipse compiler:
>
> Base: 1
> Sub: 1
> Exception in thread "main" java.lang.ClassCastException: java.lang.String
>
> And this output with javac:
>
> Base: 1
> Sub: 1
> Exception in thread "main" java.lang.ClassCastException: java.lang.String
>
> This seems to be a consistent and well-thought implementation given
> these two simple examples. Does someone else know more details about
> this issue?
>
> Coconha
>
> public class Signature {
> public Signature() {
> super();
> Sub s = new Sub();
> s.foo(new Integer(1));
> s.foo("as");
> }
> public class Base {
> public <T> void foo(T a) {
> System.out.println("Base: " + a);
> }
> }
> public class Sub extends Base {
> public <T extends Integer> void foo(T a) {
> super.foo(a);
> System.out.println("Sub: " + a);
> }
> }
> public static void main(String[] args) {
> new Signature();
> }
> }
>
>
>
|
|
|
Powered by
FUDForum. Page generated in 0.02727 seconds