lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Smiley <>
Subject Re: Lucene Bugs
Date Wed, 20 Mar 2002 05:03:38 GMT

On Tuesday, March 19, 2002, at 10:32  PM, Otis Gospodnetic wrote:

> Hello,
> --- David Smiley <> wrote:
>> I have reported bugs about Lucene in the fall of 2001 but no Lucene
>> developer has responded.  I am sending this summary as a reminder.
>> My original message to the mailing list is here:
>> [Lucene-dev] More bugs
>> The bugs at SourceForge are here:
>> DateFilter: call first
> has changed since the report, but I think I found the
> piece of code that you were referring to.
> After looking at DateFilter, TermEnum, and FilteredTermEnum it seems to
> me that next() does not need to be called first.  This is not
> java.util.Enumeration enum, it is TermEnum's enum.
> Also, if you look at methods next() and term() in FilteredTermEnum
> you'll see that term() does need to be called first, otherwise the
> first term would get skipped.

Hmmm, ok.  So this next()-method design pattern that Lucene is using 
here is not the same as how Enumeration/Iterator/ResultSet works... 
ok; water under the bridge.  I used the "find usages" feature of my 
IDE ("IDEA" by IntelliJ/Netbrains) on the method just 
now to see how other callers work with this method.  Your findings 
are correct.  I did find one caller that appears to not call it 
correctly however: TermInfosReader.readIndex() line 111.  If it is 
calling it correctly in this case for some obscure exceptional reason 
then there is documentation missing to explain why.

Anyway, the reason I first thought that this was a bug was because 
term() returned null and DateFilter.bits() was expecting it not to.  
It thus seems that that a bug does remain, and it is that 
DateFilter.bits() does not handle cases in which there are no terms 
to iterate over.

~ David Smiley

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

View raw message