> That is a static default!
Yes Uwe ... I'm aware of that :)
But that's not a static default for Lucene ... only for the application, if it chooses to use it ...
> so there are no plans to reimplement such a thing again
Well ... that's not exactly what I'm proposing here. I'm not for re-implementing any sort of staticness, unless the app chooses to use it. And please don't give me that 'there are no plans ...' answer - it kind of kills the discussion, which is not healthy for a community.
I agree that static variables might cause troubles to some deployments, BUT:
1) Not all apps are deployed on a Web Server together with other apps who happen to use Lucene.
2) Those that are deployed on web servers usually include lucene.jar in their classpath and are loaded by a different class loader than the rest ...
So we're really talking about deployments where Lucene is a common, shared library between all apps ...
And I guess that what bothers me the most is that it feels to me like we're trying to protect people from stuff we haven't yet received complaints on (at least none that I'm aware of), while we're hurting the programming experience of others ... almost recklessly. I'd hope we can find a way around that, because today I pass the same Version value around everywhere, and it's simply inconvenient. Just yesterday people complained about the need to call writer.commit() after new IW() if they want to open a reader ... one-liner inconvenience vs. dozen of lines here -- point is, what's perceived as unnecessary code DOES bother people ... only here it's just a setting thing, and my proposal is not to make it generically static. So let's not get caught on that 'static-ness'. And besides, if you ask me - variables like Version, that are needed in so many places, are usually made static ... but not in Lucene ...
So if possible ... I'd like to think how we can fix/improve the use of Version, in ways that won't break apps. Because the fact to the matter is - we invented Version to allow for changes w/o breaking back-compat, while the backwards section in CHANGES seems to grow from release to release (I know - I'm partly to blame for it :)), and another fact is that I don't remember even one complaint about a change which broke back-compat. People have raised this issue numerous times in the past, even proposed all sorts of contracts and definitions on how we can be 'allowed' to break back-compat ... but nothing came out of it.
The fact that we are not able to reach consensus doesn't mean the problem doesn't bother many out there. And ignoring the fact that currently the API looks cluttered is not doing any good. There must be away to allow some apps out there (IMO the majority) to set that Version thing once, and let Lucene use that value everywhere else ... while for others to pass it along as much as they want.
ShaiOn Tue, Apr 13, 2010 at 7:41 PM, Uwe Schindler <email@example.com> wrote:
one of the problem I have is: That is a static default! We want to get rid of them (and did it mostly, only some relicts remain), so there are no plans to reimplement such a thing again. The badest one is BooleanQuery.maxClauseCount. The same applies to all types of sysprops. As Lucene and solr is mostly running in servlet containers, this type of thing makes web applications no longer isolated. This is also a general contract for libraries: never ever rely on sysprops or statics.
H.-H.-Meier-Allee 63, D-28213 Bremen