On Tuesday, March 19, 2002, at 10:32 PM, Otis Gospodnetic wrote:
> Hello, > > --- David Smiley <[EMAIL PROTECTED]> 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 >> http://www.geocrawler.com/archives/3/2626/2001/8/0/6409669/ >> >> The bugs at SourceForge are here: >> >> DateFilter: call enum.next() first > > DateFilter.java 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 TermEnum.next() 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: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
