[
https://issues.apache.org/jira/browse/LUCENE-2285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12838942#action_12838942
]
Robert Muir commented on LUCENE-2285:
-------------------------------------
hello, i wanted to give my opinion on a few things:
* thanks for doing this cleanup work, there is a lot of good changes in here.
* as far as any flex merging troubles i will volunteer to help with that
problem.
I only have one real concern (I am not a generics policeman like Uwe so please
continue with him): i like the removal of casts, etc: but i would prefer if we
did not do this with auto-gen'd snowball code.
the only reason is i am trying to track changes over there, against over here.
it is true we changed a few things in the base class (SnowballProgram) so that
millions of reflections/string creations do not happen, but these are all
listed at the top along with the svn rev we are using. The Among, and gen'ed
code is actually now directly synced up... for now.
In truth i hate modifying this code as I hate the idea of us diverging from
their codebase, but i think the performance gains (no reflection, creating many
stringbuilders and strings, etc) are worth it. The problem is, I don't think
our local modifications are best overall for other uses of snowball, or i would
submit them to that project and sync that way. For example, they would rather
create a new StringBuilder for every input word, than run the risk of the
stemmer "keeping reference" to a potentially large string, for us this is not a
good tradeoff.
> 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
> Assignee: Uwe Schindler
> Priority: Minor
> Fix For: 3.1
>
> Attachments: LUCENE-2285.patch, LUCENE-2285.patch
>
>
> 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
