[ 
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]

Reply via email to