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

[Andy-Tatman]

On Wed, 12 Apr 2023 06:46:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> See https://bugs.java.com/bugdatabase/view_bug?bug_id=8305734
>
> The BitSet API requires that the logical size fit in an int so I think you'll end up changing the set methods to disallow an index of MAX_VALUE.
> 
> Can you change the title of the PR to match the JBS issue? The title on the PR doesn't give any context as to what this issue is about.

@AlanBateman 
It is a known issue that size() may return a negative integer, see [JDK-8230557](https://bugs.openjdk.org/browse/JDK-8230557), and the accepted workaround is to interpret the returned integer as an unsigned value and convert the output to a long. This same workaround works if a user would call length() with Integer.MAX_VALUE set. Changing the specification to reject setting Integer.MAX_VALUE may end up breaking the implementation of clients who rely on setting Integer.MAX_VALUE and use this workaround.

Furthermore, the other methods (including ones that use length()) still function correctly whether or not the Integer.MAX_VALUE bit is set, except for get(int,int) as reported here. For example, clear(int, int) works as expected if Integer.MAX_VALUE is set as length() then is not called.
Changing the specification to reject setting Integer.MAX_VALUE may break user code that use this bit and/or users that rely on the above workaround.

So while changing the specifications is possible, it can potentially break existing clients. The change suggested in this pull request avoids this and instead fixes the internal bug of the get function locally, without affecting the other methods and without affecting existing clients.

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

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