Mailing List Archive: Lucene: Java-Dev

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

Index | Next | Previous | View Threaded

jira at apache

Oct 27, 2009, 4:36 PM

Post #1 of 16 (280 views)
Permalink

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

[ 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[at]lucene.apache.org
For additional commands, e-mail: java-dev-help[at]lucene.apache.org

jira at apache

Oct 27, 2009, 4:48 PM

Post #2 of 16 (273 views)
Permalink

[jira] Commented: (LUCENE-2012) Add @Override annotations [In reply to]

[ 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[at]lucene.apache.org
For additional commands, e-mail: java-dev-help[at]lucene.apache.org

jira at apache

Oct 27, 2009, 5:01 PM

Post #3 of 16 (273 views)
Permalink

[jira] Commented: (LUCENE-2012) Add @Override annotations [In reply to]

[ 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[at]lucene.apache.org
For additional commands, e-mail: java-dev-help[at]lucene.apache.org

jira at apache

Oct 28, 2009, 12:12 AM

Post #4 of 16 (263 views)
Permalink

[jira] Commented: (LUCENE-2012) Add @Override annotations [In reply to]

[ 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[at]lucene.apache.org
For additional commands, e-mail: java-dev-help[at]lucene.apache.org

jira at apache

Oct 28, 2009, 3:27 AM

Post #5 of 16 (263 views)
Permalink

[jira] Commented: (LUCENE-2012) Add @Override annotations [In reply to]

[ 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[at]lucene.apache.org
For additional commands, e-mail: java-dev-help[at]lucene.apache.org

jira at apache

Oct 28, 2009, 9:17 AM

Post #6 of 16 (261 views)
Permalink

[jira] Commented: (LUCENE-2012) Add @Override annotations [In reply to]

[ 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[at]lucene.apache.org
For additional commands, e-mail: java-dev-help[at]lucene.apache.org

jira at apache

Oct 29, 2009, 7:05 AM

Post #7 of 16 (248 views)
Permalink

[jira] Commented: (LUCENE-2012) Add @Override annotations [In reply to]

[ 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[at]lucene.apache.org
For additional commands, e-mail: java-dev-help[at]lucene.apache.org

jira at apache

Oct 29, 2009, 7:09 AM

Post #8 of 16 (248 views)
Permalink

[jira] Commented: (LUCENE-2012) Add @Override annotations [In reply to]

[ 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[at]lucene.apache.org
For additional commands, e-mail: java-dev-help[at]lucene.apache.org

jira at apache

Oct 29, 2009, 7:13 AM

Post #9 of 16 (248 views)
Permalink

[jira] Commented: (LUCENE-2012) Add @Override annotations [In reply to]

[ 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[at]lucene.apache.org
For additional commands, e-mail: java-dev-help[at]lucene.apache.org

jira at apache

Oct 29, 2009, 7:15 AM

Post #10 of 16 (248 views)
Permalink

[jira] Commented: (LUCENE-2012) Add @Override annotations [In reply to]

[ 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[at]lucene.apache.org
For additional commands, e-mail: java-dev-help[at]lucene.apache.org

markrmiller at gmail

Oct 29, 2009, 7:17 AM

Post #11 of 16 (248 views)
Permalink

Re: [jira] Commented: (LUCENE-2012) Add @Override annotations [In reply to]

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[at]lucene.apache.org
For additional commands, e-mail: java-dev-help[at]lucene.apache.org

jira at apache

Oct 29, 2009, 2:39 PM

Post #12 of 16 (243 views)
Permalink

[jira] Commented: (LUCENE-2012) Add @Override annotations [In reply to]

[ 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[at]lucene.apache.org
For additional commands, e-mail: java-dev-help[at]lucene.apache.org

jira at apache

Nov 4, 2009, 5:57 PM

Post #13 of 16 (167 views)
Permalink

[jira] Commented: (LUCENE-2012) Add @Override annotations [In reply to]

[ 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[at]lucene.apache.org
For additional commands, e-mail: java-dev-help[at]lucene.apache.org

jira at apache

Nov 8, 2009, 9:06 AM

Post #14 of 16 (130 views)
Permalink

[jira] Commented: (LUCENE-2012) Add @Override annotations [In reply to]

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

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

Thanks Robert! I was in plane and wasn't able to do heavy committing!

> Add @Override annotations
> -------------------------
>
> Key: LUCENE-2012
> URL: https://issues.apache.org/jira/browse/LUCENE-2012
> Project: Lucene - Java
> Issue Type: Task
> Reporter: Uwe Schindler
> Assignee: 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[at]lucene.apache.org
For additional commands, e-mail: java-dev-help[at]lucene.apache.org

jira at apache

Nov 8, 2009, 9:47 AM

Post #15 of 16 (130 views)
Permalink

[jira] Commented: (LUCENE-2012) Add @Override annotations [In reply to]

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

Robert Muir commented on LUCENE-2012:
-------------------------------------

Uwe, just curious if you had this problem? when the files had funky formatting eclipse would sometimes insert the @override with the "correct" (existing) indentation, but would change the formatting of the method itself... seems like a bug... i corrected this and saw you had a similar comment...

> Add @Override annotations
> -------------------------
>
> Key: LUCENE-2012
> URL: https://issues.apache.org/jira/browse/LUCENE-2012
> Project: Lucene - Java
> Issue Type: Task
> Reporter: Uwe Schindler
> Assignee: 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[at]lucene.apache.org
For additional commands, e-mail: java-dev-help[at]lucene.apache.org

jira at apache

Nov 8, 2009, 10:32 AM

Post #16 of 16 (129 views)
Permalink

[jira] Commented: (LUCENE-2012) Add @Override annotations [In reply to]

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

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

Yes, that was exactly the problem, but it is not a bug, it simply replaced the incorrect indended line by an @Override, followed by a new line and then the correct indended method declaration. This lead to the fact, that the second line with the method declaration was looking ugly.

> Add @Override annotations
> -------------------------
>
> Key: LUCENE-2012
> URL: https://issues.apache.org/jira/browse/LUCENE-2012
> Project: Lucene - Java
> Issue Type: Task
> Reporter: Uwe Schindler
> Assignee: 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[at]lucene.apache.org
For additional commands, e-mail: java-dev-help[at]lucene.apache.org

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact lists@gossamer-threads.com