[
https://issues.apache.org/jira/browse/LUCENE-5859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Muir updated LUCENE-5859:
--------------------------------
Attachment: LUCENE-5859_dead_code.patch
Here is a patch removing all the dead code from trunk.
It doesnt "remove version.java completely" or anything like that. It changes no
runtime behavior at all.
All it does is remove useless parameters: parameters that were added way back
in the day like in Lucene 2.4 when a bug was found, that are now totally
irrelevant.
This is really simple dead code removal. There is no reason for CharArraySet to
require a Version parameter anymore, its a simple collection that just stores
strings.
Sure, its possible some of this could have a bug in the future, but we can't
add Version parameters to every api "in case it might have a bug". If it
happens, we deprecate and do the right thing if we must.
But for now, we should remove this dead code. It was a simple omission when I
tried to remove deprecations in trunk previously, I removed some of them, but I
also missed some, I didn't get all of them. Here i just do a more thorough job.
We should still rethink this version mechanism: e.g. make it an optional
parameter for those who care about it, or remove it completely. It seriously
hurts the usability of the api.
But there is no way in hell I will just leave dead code in trunk. We have to
refactor away these relics.
> Remove Version.java completely
> ------------------------------
>
> Key: LUCENE-5859
> URL: https://issues.apache.org/jira/browse/LUCENE-5859
> Project: Lucene - Core
> Issue Type: Bug
> Reporter: Robert Muir
> Fix For: 5.0
>
> Attachments: LUCENE-5859_dead_code.patch
>
>
> This has always been a mess: analyzers are easy enough to make on your own,
> we don't need to "take responsibility" for the users analysis chain for 2
> major releases.
> The code maintenance is horrible here.
> This creates a huge usability issue too, and as seen from numerous mailing
> list issues, users don't even understand how this versioning works anyway.
> I'm sure someone will whine if i try to remove these constants, but we can at
> least make no-arg ctors forwarding to VERSION_CURRENT so that people who
> don't care about back compat (e.g. just prototyping) don't have to deal with
> the horribly complex versioning system.
> If you want to make the argument that doing this is "trappy" (i heard this
> before), i think thats bogus, and ill counter by trying to remove them.
> Either way, I'm personally not going to add any of this kind of back compat
> logic myself ever again.
> Updated: description of the issue updated as expected. We should remove this
> API completely. No one else on the planet has APIs that require a mandatory
> version parameter.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
