Yes, it's legal. Misnamed for this case since you're not overriding
anything but simpler than having two annotations that server virtually
the same purpose.
Lloyd Chambers wrote:
> Thanks everyone for the very interesting followup!
>
> I've read the posts, etc, but it's still unclear to me whether
> @Override is legal or not on a sub-interface (in JDK 1.6). My original
> intent was to have the compiler enforce the claim: "This method MUST
> exist in a super-interface".
>
> Implementation doesn't matter for my intended purpose.
>
> - Every @Configured that is a PropertyBag needs to redeclare the
> getProperty() method so it can add annnotations to it;
> - No @Configured should have the getProperty() method unless it IS_A
> PropertyBag.
>
> We have this case not just for PropertyBag, but for several other
> interfaces as well eg (Named).
>
> ======== Annnotations and interface hierarchies ==========
>
> What does it mean to have an interface hierarchy with successive
> re-declarations of the same method?
> -- Do the annotations accumulate when programs go to use them?
> (Depends on how the API is used I think)
> -- Only one annotation of a given type is possible on each target in a
> given class/interface. But sub-interfaces can add another annotation
> of the same type. How does this interact with the API, and what is it
> supposed to mean for a system like HK2?
>
> Example: (http://en.wikipedia.org/wiki/Lichen)
>
> How many @GrowableStuff annotations exist on Lichen?
> How many @Override annotations?
> And is this legal in JDK 6 or not?
>
> public interface Growable {
> @GrowableStuff(...) public void grow();
> }
>
> public interface Mycobiont extends Growable {
> @Override @GrowableStuff(...) @MycobiontStuff public void grow();
> }
>
> public interface Phycobiont extends Growable {
> @Override @GrowableStuff(...) @PhycobiontStuff public void grow();
> }
>
> public interface Lichen extends Mycobiont, Phycobiont {
> @Override @GrowableStuff(...) @LichenStuff public void grow();
> }
>
>
> Lloyd
>
> On Oct 23, 2008, at 10:57 PM, Harsha Godugu wrote:
>
>>
>> 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.
>>>>>
>>>>> -
>>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>