RFR: 8305734: BitSet.get(int, int) always returns the empty BitSet when the Integer.MAX VALUE is set

[Chen Liang]

On Fri, 21 Apr 2023 15:41:55 GMT, Andy-Tatman <duke at openjdk.org> wrote:

> I would be happy to fill out the CSR, but unfortunately I don't think I am able to currently as I'm not an author on OpenJDK and as such don't have a JBS account. (I reported the bug through the Oracle site, rather than through bugs.openjdk.org .) Would you be able to help out with this?

You can provide text for the Summary, Problem, Solution, and Specification parts of the CSR in this GitHub pull request, and I can help create a CSR for you with your provided contents. See https://wiki.openjdk.org/display/csr/Fields+of+a+CSR+Request

 - The Summary describes your CSR in a few concise sentences, like "Reject interactions with Integer.MAX_VALUE bit in BitSet"
 - The Problem is what prompts the CSR, for example, it may be `BitSet.length()` may return a negative value when the `Integer.MAX_VALUE` bit is set on a non-sticky-sized bitset, created either by setting `Integer.MAX_VALUE` bit or passing in very huge buffer or arrays in `valueOf` factories.
 - The Solution is what resolves the problem described in this CSR, for example, it may be that we explicitly reject interacting with `Integer.MAX_VALUE` bit; and for array/buffer-initialized bitsets, we ignore bits higher than or equal to `Integer.MAX_VALUE `(or throw an exception if such an instance is attempted to be created), so we always have a nonnegative int length().
   - I personally recommend silently ignoring `Integer.MAX_VALUE` bit and truncating everything else beyond than throwing, since currently, all bits beyond are inaccessible due to rejection of negative indices
 - The Specification is usually the Javadoc changes that describes these behavior changes. For example, you may edit the specification of `length()` to indicate it returns nonnegative; edit the specification of `valueOf()` to indicate the bits higher than or equal to Integer.MAX_VALUE are ignored (or throw an exception to prevent such creations); and edit the specification of other methods `set` `get` etc. to reject `Integer.MAX_VALUE` as an inclusive upper-bound by throwing an `IndexOutOfRangeException`.
   - The specification changes is usually rendered as a git patch, so you can just commit your code in this pr and I can generate a patch as specification for you.

Also, you need to describe the compatibility risk: It should be "low", as existing users that access `Integer.MAX_VALUE` bit will fail in all non-sticky-sized modes. The changes to `valueOf` behavior (either silently ignore `Integer.MAX_VALUE` bit or throwing) should be mentioned as well.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13388#issuecomment-1518458234