lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Earwin Burrfoot <>
Subject Re: Lucene 2.9 and deprecated methods
Date Fri, 02 Oct 2009 23:45:35 GMT
On Sat, Oct 3, 2009 at 03:29, Uwe Schindler <> wrote:
>> It is also probably a good idea to move various settings methods from
>> IW to that builder and have IW immutable in regards to configuration.
>> I'm speaking of the likes of setWriteLockTimeout, setRAMBufferSizeMB,
>> setMergePolicy, setMergeScheduler, setSimilarity.
>> IndexWriter.Builder iwb = IndexWriter.builder().
>>   writeLockTimeout(0).
>>   RAMBufferSize(config.indexationBufferMB).
>>   maxBufferedDocs(...).
>>   similarity(...).
>>   analyzer(...);
>> ... =;
>> ... =;
> A happy user of google-collections API :-) These builders are really cool!

I feel myself caught in the act.

There is still a couple of things bothering me.
1. Introducing a builder, we'll have a whole heap of deprecated
constructors that will hang there for eternity. And then users will
scream in frustration - This class has 14(!) constructors and all of
them are deprecated! How on earth am I supposed to create this thing?
2. If someone creates IW with some reflectish javabeanish tools - he's
busted. Not that I'm feeling compassionate for such a person.

> I like Earwin's version more. A builder is very flexible, because you can
> concat all your properties (like StringBuilder works with its append method
> returning itself) and create the instance at the end.
Besides (arguably) cleaner syntax, the lack of which is (arguably) a
curse of many Java libraries,
it also allows us to return a different concrete implementation of IW
without breaking back-compat,
and also to choose this concrete implementation based on settings
provided. If we feel like doing it at some point.

Kirill Zakharenko/Кирилл Захаренко (
Home / Mobile: +7 (495) 683-567-4 / +7 (903) 5-888-423
ICQ: 104465785

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message