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

Shai Erera commented on LUCENE-2285:
------------------------------------

bq. .. not willing to add these stupid @Test everywhere

I don't share the same feeling ... I think it's a strong capability - write a 
method which doesn't need to start w/ testXYZ just to be run by JUnit (though I 
do both for clarity). I think moving to JUnit 4 only simplifies things, as it 
allows testing classes w/o the need to extend TestCase. But I'm not going to 
argue about it here, I'd like to keep this issue contained, and short. So I 
won't touch the LuceneTestCase deprecation, as it's still controversial judging 
by what you say. 

I'll remove those SuppressWarnings then?

About generics, there are the internal parts of the code, like using List, 
ArrayList etc. Scanning quickly through the list, it looks like most of the 
Lucene related warnings are about referencing them ... so it should be also 
easy to fix.

I'll take a look at the code style settings 
(http://wiki.apache.org/lucene-java/HowToContribute?action=AttachFile&do=view&target=Eclipse-Lucene-Codestyle.xml?),
 but I'm talking about compiler warnings.

> Code cleanup from all sorts of (trivial) warnings
> -------------------------------------------------
>
>                 Key: LUCENE-2285
>                 URL: https://issues.apache.org/jira/browse/LUCENE-2285
>             Project: Lucene - Java
>          Issue Type: Improvement
>            Reporter: Shai Erera
>            Priority: Minor
>             Fix For: 3.1
>
>
> I would like to do some code cleanup and remove all sorts of trivial 
> warnings, like unnecessary casts, problems w/ javadocs, unused variables, 
> redundant null checks, unnecessary semicolon etc. These are all very trivial 
> and should not pose any problem.
> I'll create another issue for getting rid of deprecated code usage, like 
> LuceneTestCase and all sorts of deprecated constructors. That's also trivial 
> because it only affects Lucene code, but it's a different type of change.
> Another issue I'd like to create is about introducing more generics in the 
> code, where it's missing today - not changing existing API. There are many 
> places in the code like that.
> So, with you permission, I'll start with the trivial ones first, and then 
> move on to the others.

-- 
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-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org

Reply via email to