[jira] Created: (LUCENE-2012) Add @Override annotations

Add @Override annotations
-------------------------

                 Key: LUCENE-2012
                 URL: https://issues.apache.org/jira/browse/LUCENE-2012
             Project: Lucene - Java
          Issue Type: Task
            Reporter: Uwe Schindler
             Fix For: 3.0


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: java-dev-unsubscribe@...
For additional commands, e-mail: java-dev-help@...

     [ https://issues.apache.org/jira/browse/LUCENE-2012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Uwe Schindler updated LUCENE-2012:
----------------------------------

    Attachment: LUCENE-2012.patch

Patch.

> Add @Override annotations
> -------------------------
>
>                 Key: LUCENE-2012
>                 URL: https://issues.apache.org/jira/browse/LUCENE-2012
>             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: java-dev-unsubscribe@...
For additional commands, e-mail: java-dev-help@...

    [ https://issues.apache.org/jira/browse/LUCENE-2012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12770700#action_12770700 ]

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: https://issues.apache.org/jira/browse/LUCENE-2012
>             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: java-dev-unsubscribe@...
For additional commands, e-mail: java-dev-help@...

    [ https://issues.apache.org/jira/browse/LUCENE-2012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12770705#action_12770705 ]

DM Smith commented on LUCENE-2012:
----------------------------------

Uwe, what did you use to generate the @override?

> Add @Override annotations
> -------------------------
>
>                 Key: LUCENE-2012
>                 URL: https://issues.apache.org/jira/browse/LUCENE-2012
>             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: java-dev-unsubscribe@...
For additional commands, e-mail: java-dev-help@...

    [ https://issues.apache.org/jira/browse/LUCENE-2012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12770711#action_12770711 ]

Uwe Schindler commented on LUCENE-2012:
---------------------------------------

I use normally only my text editor for developing, but for such a thing, Eclipse is good:
Right mouse on src/java folder, Source -> Cleanup - Use Custom Profile -> remove everything except "add missing @Override"

> Add @Override annotations
> -------------------------
>
>                 Key: LUCENE-2012
>                 URL: https://issues.apache.org/jira/browse/LUCENE-2012
>             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: java-dev-unsubscribe@...
For additional commands, e-mail: java-dev-help@...

    [ https://issues.apache.org/jira/browse/LUCENE-2012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12770812#action_12770812 ]

Earwin Burrfoot commented on LUCENE-2012:
-----------------------------------------

That's why you need @override in first place - any decent Java IDE shows that method overrides/has overrides.

> Add @Override annotations
> -------------------------
>
>                 Key: LUCENE-2012
>                 URL: https://issues.apache.org/jira/browse/LUCENE-2012
>             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: java-dev-unsubscribe@...
For additional commands, e-mail: java-dev-help@...

    [ https://issues.apache.org/jira/browse/LUCENE-2012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12770882#action_12770882 ]

Uwe Schindler commented on LUCENE-2012:
---------------------------------------

If nobody objects, I will commit during the day. And then do the same with tests/contrib.

> Add @Override annotations
> -------------------------
>
>                 Key: LUCENE-2012
>                 URL: https://issues.apache.org/jira/browse/LUCENE-2012
>             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: java-dev-unsubscribe@...
For additional commands, e-mail: java-dev-help@...

    [ https://issues.apache.org/jira/browse/LUCENE-2012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12770975#action_12770975 ]

Uwe Schindler commented on LUCENE-2012:
---------------------------------------

Committed trunk changes in revision: 830661

I will proceed with contrib and test later (not yet).

> Add @Override annotations
> -------------------------
>
>                 Key: LUCENE-2012
>                 URL: https://issues.apache.org/jira/browse/LUCENE-2012
>             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: java-dev-unsubscribe@...
For additional commands, e-mail: java-dev-help@...

    [ https://issues.apache.org/jira/browse/LUCENE-2012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12771423#action_12771423 ]

Cédrik LIME commented on LUCENE-2012:
-------------------------------------

This patch breaks compatibility with Java 5!
@Override annotations are only available on *interface implementation* from Java 1.6

> Add @Override annotations
> -------------------------
>
>                 Key: LUCENE-2012
>                 URL: https://issues.apache.org/jira/browse/LUCENE-2012
>             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: java-dev-unsubscribe@...
For additional commands, e-mail: java-dev-help@...

    [ https://issues.apache.org/jira/browse/LUCENE-2012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12771424#action_12771424 ]

Uwe Schindler commented on LUCENE-2012:
---------------------------------------

There are no @Overrides on interfaces.

By the way, I always-ever use 1.5. I do not have any shitty  1.6 on my computer :-)

> Add @Override annotations
> -------------------------
>
>                 Key: LUCENE-2012
>                 URL: https://issues.apache.org/jira/browse/LUCENE-2012
>             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: java-dev-unsubscribe@...
For additional commands, e-mail: java-dev-help@...

    [ https://issues.apache.org/jira/browse/LUCENE-2012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12771426#action_12771426 ]

Cédrik LIME commented on LUCENE-2012:
-------------------------------------

Oops, my mistake, sorry.
'twas my workspace I didn't upgrade from 1.4... :-(
Mea culpa!

> Add @Override annotations
> -------------------------
>
>                 Key: LUCENE-2012
>                 URL: https://issues.apache.org/jira/browse/LUCENE-2012
>             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: java-dev-unsubscribe@...
For additional commands, e-mail: java-dev-help@...

    [ https://issues.apache.org/jira/browse/LUCENE-2012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12771428#action_12771428 ]

Uwe Schindler commented on LUCENE-2012:
---------------------------------------

No problem :) But then it should also have stopped at generics :-]

> Add @Override annotations
> -------------------------
>
>                 Key: LUCENE-2012
>                 URL: https://issues.apache.org/jira/browse/LUCENE-2012
>             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: java-dev-unsubscribe@...
For additional commands, e-mail: java-dev-help@...

[markrmiller]

You vulgar Germans :) Think of the poor, naive American children.

Uwe Schindler (JIRA) wrote:

>     [ https://issues.apache.org/jira/browse/LUCENE-2012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12771428#action_12771428 ]
>
> Uwe Schindler commented on LUCENE-2012:
> ---------------------------------------
>
> No problem :) But then it should also have stopped at generics :-]
>
>  
>> Add @Override annotations
>> -------------------------
>>
>>                 Key: LUCENE-2012
>>                 URL: https://issues.apache.org/jira/browse/LUCENE-2012
>>             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)?
>>    
>
>  

--
- Mark

http://www.lucidimagination.com




---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@...
For additional commands, e-mail: java-dev-help@...

    [ https://issues.apache.org/jira/browse/LUCENE-2012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12771635#action_12771635 ]

Mark Miller commented on LUCENE-2012:
-------------------------------------

What about tests and contrib Uwe? Shouldn't we just hit them all?

> Add @Override annotations
> -------------------------
>
>                 Key: LUCENE-2012
>                 URL: https://issues.apache.org/jira/browse/LUCENE-2012
>             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: java-dev-unsubscribe@...
For additional commands, e-mail: java-dev-help@...

    [ https://issues.apache.org/jira/browse/LUCENE-2012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12771635#action_12771635 ]

Mark Miller edited comment on LUCENE-2012 at 10/29/09 9:43 PM:
---------------------------------------------------------------

What about tests and contrib Uwe? Shouldn't we just hit them all?

*edit*

scratch that - sorry - missed your comment that you will do contrib/tests next

      was (Author: markrmiller@...):
    What about tests and contrib Uwe? Shouldn't we just hit them all?
 

> Add @Override annotations
> -------------------------
>
>                 Key: LUCENE-2012
>                 URL: https://issues.apache.org/jira/browse/LUCENE-2012
>             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: java-dev-unsubscribe@...
For additional commands, e-mail: java-dev-help@...

     [ https://issues.apache.org/jira/browse/LUCENE-2012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Uwe Schindler updated LUCENE-2012:
----------------------------------

    Attachment: LUCENE-2012-tests.patch

test for the patches, it also fixes whitespace where broken.

Will commit now.

> Add @Override annotations
> -------------------------
>
>                 Key: LUCENE-2012
>                 URL: https://issues.apache.org/jira/browse/LUCENE-2012
>             Project: Lucene - Java
>          Issue Type: Task
>            Reporter: Uwe Schindler
>             Fix For: 3.0
>
>         Attachments: LUCENE-2012-tests.patch, 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: java-dev-unsubscribe@...
For additional commands, e-mail: java-dev-help@...

    [ https://issues.apache.org/jira/browse/LUCENE-2012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12773743#action_12773743 ]

Uwe Schindler commented on LUCENE-2012:
---------------------------------------

Committed revision: 832972

> Add @Override annotations
> -------------------------
>
>                 Key: LUCENE-2012
>                 URL: https://issues.apache.org/jira/browse/LUCENE-2012
>             Project: Lucene - Java
>          Issue Type: Task
>            Reporter: Uwe Schindler
>             Fix For: 3.0
>
>         Attachments: LUCENE-2012-tests.patch, 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: java-dev-unsubscribe@...
For additional commands, e-mail: java-dev-help@...

    [ https://issues.apache.org/jira/browse/LUCENE-2012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12773740#action_12773740 ]

Uwe Schindler edited comment on LUCENE-2012 at 11/5/09 2:50 AM:
----------------------------------------------------------------

test for the patches, it also fixes whitespace where broken. *EDIT* other way round: patch for the tests

Will commit now.

      was (Author: thetaphi):
    test for the patches, it also fixes whitespace where broken.

Will commit now.
 

> Add @Override annotations
> -------------------------
>
>                 Key: LUCENE-2012
>                 URL: https://issues.apache.org/jira/browse/LUCENE-2012
>             Project: Lucene - Java
>          Issue Type: Task
>            Reporter: Uwe Schindler
>             Fix For: 3.0
>
>         Attachments: LUCENE-2012-tests.patch, 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: java-dev-unsubscribe@...
For additional commands, e-mail: java-dev-help@...

     [ https://issues.apache.org/jira/browse/LUCENE-2012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Robert Muir updated LUCENE-2012:
--------------------------------

    Attachment: LUCENE-2012_contrib.patch

Uwe attached is a patch for contrib and its tests.

> Add @Override annotations
> -------------------------
>
>                 Key: LUCENE-2012
>                 URL: https://issues.apache.org/jira/browse/LUCENE-2012
>             Project: Lucene - Java
>          Issue Type: Task
>            Reporter: Uwe Schindler
>             Fix For: 3.0
>
>         Attachments: LUCENE-2012-tests.patch, LUCENE-2012.patch, LUCENE-2012_contrib.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: java-dev-unsubscribe@...
For additional commands, e-mail: java-dev-help@...

     [ https://issues.apache.org/jira/browse/LUCENE-2012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Robert Muir updated LUCENE-2012:
--------------------------------

    Attachment: LUCENE-2012_contrib.patch

there were some places where @override was added for generated code (snowball, javacc), I excluded these files, as was done for core.

also add @override for demo. will commit and resolve this soon as this will quickly get out of date.

> Add @Override annotations
> -------------------------
>
>                 Key: LUCENE-2012
>                 URL: https://issues.apache.org/jira/browse/LUCENE-2012
>             Project: Lucene - Java
>          Issue Type: Task
>            Reporter: Uwe Schindler
>             Fix For: 3.0
>
>         Attachments: LUCENE-2012-tests.patch, LUCENE-2012.patch, LUCENE-2012_contrib.patch, LUCENE-2012_contrib.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: java-dev-unsubscribe@...
For additional commands, e-mail: java-dev-help@...