Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #30891 > unrolled thread

Co-/Contravariance and @Override...

Back to article view | Back to comp.lang.java.programmer

Contents

  Co-/Contravariance and @Override... Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2015-01-25 18:12 +0000
    Re: Co-/Contravariance and @Override... Lothar Kimmeringer <news200709@kimmeringer.de> - 2015-01-26 00:52 +0100
      Re: Co-/Contravariance and @Override... Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2015-01-26 01:52 +0000
    Re: Co-/Contravariance and @Override... Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2015-01-26 01:46 +0000

#30891 — Co-/Contravariance and @Override...

Say some given interface Foo (from a 3rd party lib) specifies a method:
  void foo(String s);

Now, I'm implementing a class, that implements the above-mentioned
interface Foo, but I want my foo-method to be more general, and allow
it to take any CharSequence.

class MyFoo extends MyBase implements Foo {
   @Override public void foo(CharSequence c) { ... }
}

For reasons I do not quite understand, eclipse complains about it.
Eclipse claims that my foo method doesn't merit the @Override.
Why not?  Isn't it so, that subclasses can be more lenient about
accepted types, as long as the inherited constraints are met?

I am working around it, by just making two "foo"s: one for String
and one for CharSequence and let one call the other, but I'd really
want to understand my mistake (or - less likely - eclipse's).

Is co-/contravariance only allowed with methods from super*classes*
but perhaps not with methods from interfaces?

[toc] | [next] | [standalone]

#30903

Andreas Leitgeb wrote:

> class MyFoo extends MyBase implements Foo {
>    @Override public void foo(CharSequence c) { ... }
> }
> 
> For reasons I do not quite understand, eclipse complains about it.
> Eclipse claims that my foo method doesn't merit the @Override.
> Why not?  Isn't it so, that subclasses can be more lenient about
> accepted types, as long as the inherited constraints are met?

You're not overwriting a method but implementing an interface,
so the Overwrite-annotation can't be used at all. Some versions
of Eclipse accept that, though.


Regards, Lothar
-- 
Lothar Kimmeringer                E-Mail: spamfang@kimmeringer.de
               PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)

Always remember: The answer is forty-two, there can only be wrong
                 questions!

--- news://freenews.netfront.net/ - complaints: news@netfront.net ---

[toc] | [prev] | [next] | [standalone]

#30905

Lothar Kimmeringer <news200709@kimmeringer.de> wrote:
> Andreas Leitgeb wrote:
>> class MyFoo extends MyBase implements Foo {
>>    @Override public void foo(CharSequence c) { ... }
>> }
>> For reasons I do not quite understand, eclipse complains about it.
>> Eclipse claims that my foo method doesn't merit the @Override.
>> Why not?  Isn't it so, that subclasses can be more lenient about
>> accepted types, as long as the inherited constraints are met?
> You're not overwriting a method but implementing an interface,
> so the Overwrite-annotation can't be used at all. Some versions
> of Eclipse accept that, though.

That was indeed a problem once. But the Annotation's meaning
was generalized later, to include "@Implements"-semantics.

My problem was meanwhile solved by Stefan Ram.

[toc] | [prev] | [next] | [standalone]

#30904

Stefan Ram <ram@zedat.fu-berlin.de> wrote:
> Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> writes:
>>Is co-/contravariance only allowed with methods from super*classes*
>>but perhaps not with methods from interfaces?

>   There is no (contra)variance with parameter types at all.

Oh, I must have gathered that wrongly (aka "misread" it), then.
(Or maybe I just over-generalized it from the return types.)

Thanks for clarifying!

>   The following does not compile too:
> class A { public void f( final java.lang.String s ){} }
> final class B extends A { @java.lang.Override public void f
>   ( final java.lang.CharSequence s ){} }
>
> public final class Main
> { public static void main( final java.lang.String args[] )
>   {} }
>
>   You /can/ have covariant /result/ types since Java 1.5
>   following the Liskov substitution principle:
>
> class A { public java.lang.CharSequence f(  ){ return ""; } }
> final class B extends A { @java.lang.Override public
>   java.lang.String f(){ return ""; } }
>
> public final class Main
> { public static void main( final java.lang.String args[] )
>   {} }
>

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web