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
>