Repository navigation
4.3.0: BitSet.clear() fails with flowexpr.parse.index.too.big — @SideEffectsOnly("#1") on a no-arg method #8325
Description
Problem
Since 4.3.0, any call to the no-arg BitSet.clear() fails the Nullness Checker:
Repro.java:5: error: [flowexpr.parse.index.too.big] the method has no parameter #1 (total 0 parameters)
bits.clear();
^
It worked on 4.2.2.
Reproduce
import java.util.BitSet;
class Repro {
void reset(BitSet bits) {
bits.clear();
}
}javac -proc:only \
-cp checker-qual-4.3.0.jar \
-processorpath checker-4.3.0.jar:checker-qual-4.3.0.jar \
-processor org.checkerframework.checker.nullness.NullnessChecker \
Repro.java
With 4.2.2 jars: no errors. With 4.3.0 jars: the error above.
JDK: 21.0.3.
Cause
4.3.0 added @SideEffectsOnly("#1") to all three clear overloads in annotated-jdk/src/java.base/share/classes/java/util/BitSet.java:
@SideEffectsOnly("#1")
public void clear(@GuardSatisfied BitSet this, @NonNegative int bitIndex);
@SideEffectsOnly("#1")
public void clear(@GuardSatisfied BitSet this, @NonNegative int fromIndex, @NonNegative int toIndex);
@SideEffectsOnly("#1")
public void clear(@GuardSatisfied BitSet this);On clear(), #1 doesn't exist, which causes the error. On the other two overloads, #1 is an int index, but the method mutates the receiver. So "this" looks like the intended value for all three:
@SideEffectsOnly("this")
Activity
mernst commentedon Oct 7, 2026
Thank you for the bug report, and I'm sorry about the problem. You are right about the root cause. #8326 and typetools/jdk#302 fix the problem. We can make a snapshot release or a 4.3.1 release if you need that.
d9zbglobal commentedon Oct 8, 2026
4.3.1 release would be very much appreciated - just hit this one today.
Test case for issue #8325 (#8326)
mernst commentedon Oct 8, 2026
We made the release. Please let us know of any other problems you encounter.
d9zbglobal commentedon Oct 9, 2026
Thank you very much - amazingly quick!