Thank you Mike!
On 05.05.2014 21:37, Mike Duigou wrote:
The fix looks good though I wonder if the conditional checks can be optimized a
bit.
Hm. I don't see lots of room for optimization here without revising
nexSetBit() and nextClearBit() implementation.
The first check at 1190 is already used to catch two cases:
- at the first entrance into the loop, when i was MAX_VALUE,
- at the other cycles, when endOfRun was either MAX_VALUE or -1.
I am concerned that the suggested iteration method provided in the nextSetBit()
javadoc induces the same failure we just corrected. Perhaps we should revise
that advice?
Yes. I added a check into the loop. It seems to be the simplest way to
make the sample correct.
Would you please take a look at the updated webrev?
http://cr.openjdk.java.net/~igerasim/8040806/1/webrev/
Sincerely yours,
Ivan
Mike
On May 5 2014, at 09:56 , Ivan Gerasimov <ivan.gerasi...@oracle.com> wrote:
Hello!
This is a friendly reminder.
Could a Reviewer please review/approve this fix?
The problem is that a BitSet can have bit # MAX_VALUE set, but trying to
convert it to String throws an exception.
Sincerely yours,
Ivan
On 22.04.2014 16:13, Ivan Gerasimov wrote:
Hello!
If a BitSet has the bit Integer.MAX_VALUE set, then calling toString() will
throw an exception.
The same thing happens if the bit (Integer.MAX_VALUE-1) is set.
Would you please help review the fix for this issue?
BUGURL: https://bugs.openjdk.java.net/browse/JDK-8040806
WEBREV: http://cr.openjdk.java.net/~igerasim/8040806/0/webrev/
Sincerely yours,
Ivan
