-
Notifications
You must be signed in to change notification settings - Fork 1.3k
chore: Seal BitSet to only allow FixedBitSet and SparseFixedBitSet #15161
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
10.3 is cut, so cannot go there. Possibly 10.4. But I would expect this to be a v11 change. |
* @lucene.internal | ||
*/ | ||
public abstract class BitSet implements Bits, Accountable { | ||
public abstract sealed class BitSet implements Bits, Accountable |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you add a small comment explaining that we're doing this to help call sites of methods on the BitSet
class be bimorphic at most, to help with performance?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
added small comment explaining this.
lucene/CHANGES.txt
Outdated
(Ben Trent) | ||
|
||
* GITHUB#15038: BitSet is now a sealed abstract class permitting only FixedBitSet and SparseFixedBitSet. | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's move this to 11.0?
final int numBits = 1 + random().nextInt(100000); | ||
for (float percentSet : new float[] {0, 0.01f, 0.1f, 0.5f, 0.9f, 0.99f, 1f}) { | ||
BitSet set1 = new JavaUtilBitSet(randomSet(numBits, percentSet), numBits); | ||
BitSet set1 = fromJavaUtilBitSet(randomSet(numBits, percentSet), numBits); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
E.g. doing just java.util.BitSet set1 = randomSet(numBits, percentSet);
should be good enough here since we're only comparing cardinalities?
return randomSet(numBits, (int) (percentSet * numBits)); | ||
} | ||
|
||
protected abstract T fromJavaUtilBitSet(java.util.BitSet set, int numBits); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I worry that copying from a java.util.BitSet
defeats the purpose of the test, since most tests would be comparing two same implementations of BitSet
instead of JavaUtilBitSet
vs. a BitSet
implementation. Can we try to refactor tests to work directly against a java.util.BitSet
without copying to a BitSet
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
tried refactoring it using java.util.Bitset.
Had to hack through two issues.
java.util.BitSet.nextSetBit()
returns-1
when there are no more set bits while lucene Bitset returnDocIdSetIterator.NO_MORE_DOCS
i.e. 2147483647.java.util.BitSet.clear()
throws error if from > to while lucene does nothing.
54d2e50
to
472d630
Compare
Closes #15038
correct BitSet implementation from a java.util.BitSet for testing.
This ensures that only Lucene’s optimized implementations of BitSet are allowed, preventing
accidental performance regressions from custom subclasses, while keeping existing tests valid.