Here is a patch:

• oal.util.BitSet has the get/set/clear methods you would expect on a BitSet
• SparseFixedBitSet and FixedBitSet extend BitSet
• BitSet also has nextSetBit but the contract of this method has been changed to return 2^31-1 instead of -1 when there are no more bits set, it makes it possible to reuse this method in DocIdSetIterator.advance/nextDoc
• BitSet also has default implementations for and(DISI), or(DISI) and andNot(DISI) than can be overridden by sub-classes (eg. FixedBitSet does)
• or/and/andNot have also been added to DocIdSetBuilder
• BooleanFilter now uses DocIdSetBuilder to build the bitset of matching docs instead of enforcing a FixedBitSet (so it will sometimes use a SparseFixedBitSet when data is sparse)

Cool.

In the patch you have the abstract cardinality() method on BitSet abstract, too. So BitDocIdSet's 2nd ctor does not need to be specialized to FixedBitSet?

Good point Uwe. The reason why I did it this way is that for SparseFixedBitSet it makes more sense to use #aproximateCardinality() to get a cost. So I refactored a bit the patch to add an #approximateCardinality() method on BitSet that forwards to #cardinality() for FixedBitSet and is overridden by SparseFixedBitSet to use linear counting. Then BitDocIdSet's 2nd constructor doesn't specialize for FixedBitSet and uses approximateCardinality to get a cost in all cases. Does it make sense to you?

That is fine to me! I was just wondering why you did this specialization at all. Thanks for the explanation!

Commit 1634012 from Adrien Grand in branch 'dev/trunk'
[ https://svn.apache.org/r1634012 ]

LUCENE-6021: Make SparseFixedBitSet and FixedBitSet share a common "BitSet" interface.

Commit 1634013 from Adrien Grand in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1634013 ]

LUCENE-6021: Make SparseFixedBitSet and FixedBitSet share a common "BitSet" interface.

Bulk close after 5.0 release.