lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Miller (JIRA)" <>
Subject [jira] Commented: (LUCENE-2012) Add @Override annotations
Date Tue, 27 Oct 2009 23:36:59 GMT


Mark Miller commented on LUCENE-2012:

+1 - I've felt this pain. 

Also, in keeping the flex branch up to date, I've seen that
the recent trurn has been incredible. Addng this to the mix 
isn't going to put things over any tipping point IMO. If there is a patch
out there that hasn't been severely affected recently, it's small
enough not to matter - and I've swalled so many merges on the flex
branch that I don't much care about swallowing this patch too. 
Easy merging with this one ;)

> Add @Override annotations
> -------------------------
>                 Key: LUCENE-2012
>                 URL:
>             Project: Lucene - Java
>          Issue Type: Task
>            Reporter: Uwe Schindler
>             Fix For: 3.0
>         Attachments: LUCENE-2012.patch
> During removal of deprecated APIs, mostly the problem was, to not only remove the method
in the (abstract) base class (e.g. Scorer.explain()), but also remove it in sub classes that
override it. You can easily forget that (especially, if the method was not marked deprecated
in the subclass). By adding @Override annotations everywhere in Lucene, such removals are
simple, because the compiler throws out an error message in all subclasses which then no longer
override the method.
> Also it helps preventing the well-known traps like overriding hashcode() instead of hashCode().
> The patch was generated automatically, and is rather large. Should I apply it, or would
it break too many patches (but I think, trunk has changed so much, that this is only a minimum
of additional work to merge)?

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message