[
https://issues.apache.org/jira/browse/SOLR-14469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17154692#comment-17154692
]
Erick Erickson commented on SOLR-14469:
---------------------------------------
"The negatives are currently no-ops" Yeah, I understand that. Patience! I'll
get to this JIRA soon ;) I hope.
FWIW, I consider this JIRA something of a placeholder. I intend to dive into
this and hack around for a while to see what patterns emerge. Your suggestions
here are probably the way it'll go, this discusssion has saved me some fumbling
around.
Part of the motivation is code clean-up, I think we have stuff deprecated in 4x
or earlier that's never been cleaned up. It's also extremely frustrating to see
deprecation annotations with no indication of _when_ they were deprecated or
_what_ to use in their place. I think of it as another barrier to keeping code
clean that we can/should remove. I'm also certain that the person doing the
deprecation has the very best chance of efficiently updating the usages at the
time the call is deprecated!
So my tentative thoughts here are:
1> do some labeling enforcement. Require the deprecation to say when and what
to use instead. TBD is how that interacts with javadocs checks.
2> Yeah, I don't see how to fail compilations and still evolve the code. I like
in-your-face failures waaaay early in the process, but the end goal of not
allowing cruft to accumulate is served by check failures.
3> I like the forbiddenAPIs idea and I know you put some effort into that in
Gradle that I haven't looked at how to use yet ;). We can use this approach to
build up one fix at a time; that'd allow gradual improvement rather than the
sledgehammer of using compile failures which is untenable.
It also provides a mechanism for cleaning things up when the deprecations are
made. I'd really like to _strongly_ encourage people who add deprectations to
clean up the internal usages at the same time since they know exactly what to
do (at least they better!). For use-cases that require the deprecated calls to
stay (say changing a method's visibility as someone pointed out) we can use
SuppressForbidden.
4> As far as actually removing deprecation annotations, I think there are two
phases:
4.1> I see no reason we can't "do the right thing" in trunk for any deprecation
added prior to 8.0. It won't always be removing the code.
4.2> For deprecations added in 8x, fix up all the internal calls and add them
to ForbiddenAPIs.
This is my straw-man proposal, as I mentioned before I'll try doing some of it
and see if it makes sense and report back.
Thanks again for your suggestions, they really helped me clarify a path
forward. Any plan is better than fumbling around blindly, even if it turns out
to be sub-optimal...
> Removed deprecated code in solr/core (master only)
> --------------------------------------------------
>
> Key: SOLR-14469
> URL: https://issues.apache.org/jira/browse/SOLR-14469
> Project: Solr
> Issue Type: Sub-task
> Reporter: Erick Erickson
> Assignee: Erick Erickson
> Priority: Major
>
> I'm currently working on getting all the warnings out of the code, so this is
> something of a placeholder for a week or two.
> There will be sub-tasks, please create them when you start working on a
> project.
--
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
