[
https://issues.apache.org/jira/browse/LUCENE-9394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17130608#comment-17130608
]
Erick Erickson commented on LUCENE-9394:
----------------------------------------
Glad you’re looking at this.
If you think some of the Lucene code is “filthy with SuppressWarnings”, you
should see some of the code I’m checking in ;). I’ve made a conscious decision
to make it ugly (trying to suppress warnings on as small a unit as possible
rather than whole classes and the like; did you know you can add that
annotation on a parameter to a method?) purposely. Maybe some of it’ll be fixed
by-the-by if it offends peoples sense of tidiness.
You’re going deeper than I can afford to given the number of warnings in Solr,
but this is where I’d eventually like to be. I’m sounding like a broken record,
but my goal for the Solr code short-term is just to have a chance to stop
getting _worse_.
About deprecation warnings. Admittedly I haven’t started looking at
deprecations yet. On the surface, though, we ought to be able to remove
deprecated code that was introduced X-2 ago. Or, if the intent of the
deprecation was to make something private, say, make it private and remove the
annotation. As far as our internal code is concerned, why can’t we fix any
deprecation usages when they’re introduced? Ideally I’d like to fail
compilation on deprecation usage as a general rule. I’m sure there’d be
exceptions, particularly with code we don’t control but I suspect that could be
worked around.
Again ideally, I’d like precommit to fail unless there were two things in
deprecation annotations: 1> a note about what to use instead and 2> a version
stamp for _when_ it was deprecated. If that were in place, we could start
failing precommit if the current version were X+2 from the version stamp in the
deprecation annotation. IDK whether that’s practical, master and the current
release tree might diverge too much.
I’ll be opening a JIRA to discuss what to do when I get to the point. Which
ought not to be too long, I’m ripping through the Solr warnings pretty quickly
since what I’m doing is so simple.
I’ll look forward to your input on that JIRA now that you’ve worked through one
set of changes and have more “eyes on” than I have.
Erick
> Fix or suppress compile-time warnings
> -------------------------------------
>
> Key: LUCENE-9394
> URL: https://issues.apache.org/jira/browse/LUCENE-9394
> Project: Lucene - Core
> Issue Type: Improvement
> Reporter: Michael Sokolov
> Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This is a spinoff from [~erickerickson]'s efforts over in SOLR-10778
> The goal is a warning-free compilation, followed by enforcement of build
> failure on warnings, with the idea of suppressing innocuous warnings to the
> extent that the remaining warnings be treated as build failure.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
