Kedar Mhaswade wrote:
> I followed up some more on this topic and now the things are clearer
> a bit now. See:
>
> http://blogs.sun.com/ahe/entry/override -- Peter's Ahe's blog-post
> http://forums.sun.com/thread.jspa?messageID=10478202 -- this question
> posed at invaluable Sun Java forums!
>
> Regards,
> Kedar
>
> PS - I still don't understand the comment
>
> interface A {
> void m();
> }
>
> interface B extends A {
> void m(); // overrides but doesn't implement
> }
>
> from Peter's blog-post because I think B:m() does not override
> A:m() as both of these are interfaces.
>
>
> Lloyd Chambers wrote:
>
>> Kedar,
>>
>> I think it's still unclear. We do override method signatures in our
>> interfaces (to provide annotations). So it seemed appropriate.
>>
>> Lloyd
>>
>> On Oct 23, 2008, at 4:21 PM, Kedar Mhaswade wrote:
>>
>>>> I read the Javadoc for @Override and there is no indication it is
>>>> for only implementation. And I think it makes sense for
>>>> sub-interfaces; the same reasons apply (mis-spelling, verify that a
>>>> parent interface has the same signature, etc). In our case, we
>>>> have redundant (overridden) method for several things, not just
>>>> this case.
>>>
>>>
Take a read at this API doc:
>>> Quoting Javadoc:
>>> "Indicates that a method declaration is intended to override a
>>> method declaration in a superclass. If a method is annotated with
>>> this annotation type but does not override a superclass method,
>>> compilers are required to generate an error message."
>>>
Its clear that , it talk about class. And the term "override" is in
the context of traditional C++ (OO) context.
What is puzzling to me is, at what scenarios compiler (of 1.6)
generate error?
(I also don't see a difference in API doc from 1.5uxx to 1.6uxx)
-hg
>>> I see "class" being stressed here. Of course, you can use it for
>>> interfaces, but
>>> I don't think it is the intent. You "override" implementation of a
>>> method in a
>>> subclass, not subinterface.
>>>
>>> -
>>