[
https://issues.apache.org/jira/browse/LUCENE-5859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14080745#comment-14080745
]
Uwe Schindler commented on LUCENE-5859:
---------------------------------------
Thanks Robert. One suggestion to think about:
We can do something like you think. But instead of using LUCENE_CURRENT as
default in this(Version.LUCENE_CURRENT), how about this anti-pattern, but maybe
useful here.
We could add a static setter to the Version enum called
Version#setDefault(Version). This static setter would then automatically affect
all constructors without a Version. So the delegation would be:
{{this(Version.getDefault());}}
By default Verseion.getDefault() returns LUCENE_CURRENT, but somebody who
upgrades can set a static default. I know static sefaults are horrible in
multi-application servers, because one webapp could affect another one. But its
better than nothing here.
> 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]