On 24 June 2012 13:42, Adrian Crum <adrian.c...@sandglass-software.com> wrote:
> On 6/24/2012 12:25 PM, sebb wrote:
>>
>> On 24 June 2012 10:28, Thomas Neidhart <thomas.neidh...@gmail.com> wrote:
>>>
>>> Hi,
>>>
>>> I recently started to work more on collections and cleaning up the trunk
>>> to make it a candidate for a release and would like to ask a few
>>> questions:
>>>
>>>  - there is still lots of javadoc missing, moving the source code level
>>>   to Java 1.6 would allow the use of @Override in more places (instead
>>>   of putting a /** {inheritDoc} */ everywhere)
>>
>> AFAICT Javadoc is automatically inherited for methods that implement
>> an interface.
>> Being able to add @Override to an interface implementation does not
>> gain anything.
>
>
> True, you don't gain anything in JavaDocs, but it is still worth adding
> because the compiler will let you know if your implementation does not match
> the interface.

Not in the short term, as the most likely scenario is to just add
@Override to all implementing methods when prompted by the
compiler/IDE.

There are likely too many methods to examine each to see if it should
be an implementing method or not.
And if there is an existing method that was intended to implement an
interface, but does not, it won't catch that.
The only way to catch that is to look at each method individually and
see if it should override or implement something.

This checking can be done already in any decent IDE.

In the longer term, the most likely benefit is that it will flag
unused implementations, e.g. if a class drops an interface.
It will only help with maintenance if the committer adds @Override as
part of any new code.
That often does not happen with Java 5 overrides, so the same will be
true of interface overrides.

That's not to say it should not be used, but at best it is a
side-benefit of Java 6.
It's not a good reason on its own to move to Java 6.

> -Adrian
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Reply via email to