[
https://issues.apache.org/jira/browse/SOLR-2288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12972114#action_12972114
]
Hoss Man commented on SOLR-2288:
--------------------------------
bq. just the implementation is different.
fair enough -- i ment i was trying to avoid changes to either the APIs or the
internals, just focusing on the quick wins that were easy to review at a glance
and shouldn't affect the bytecode (Collection<Object> instead of Collection;
etc...)
I don't expect that *all* compiler warnings can be dealt with using trivial
patches, but that's what i was trying to focus on in this issue.
changes to the internals of specific classes seem like they should be tracked
in distinct issues with more visibility
> clean up compiler warnings
> --------------------------
>
> Key: SOLR-2288
> URL: https://issues.apache.org/jira/browse/SOLR-2288
> Project: Solr
> Issue Type: Improvement
> Reporter: Hoss Man
> Attachments: SOLR-2288_namedlist.patch, warning.cleanup.patch
>
>
> there's a ton of compiler warning in the solr tree, and it's high time we
> cleaned them up, or annotate them to be suppressed so we can start making a
> bigger stink when/if code is added to the tree thta produces warnings (we'll
> never do a good job of noticing new warnings when we have ~175 existing ones)
> Using this issue to track related commits
> The goal of this issue should not be to change any functionality or APIs,
> just deal with each warning in the most appropriate way;
> * fix generic declarations
> * add SuppressWarning anotation if it's safe in context
--
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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
