RFR: 8300487: Store cardinality as a field in BitSet [v5]

[Jim Laskey]

On Wed, 18 Jan 2023 12:43:31 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> The enanchment is useful for applications that make heavy use of BitSet objects as sets of integers, and therefore they need to make a lot of calls to cardinality() method, which actually require linear time in the number of words in use by the bit set.
>> This optimization reduces the cost of calling cardinality() to constant time, as it simply returns the value of the field, and it also try to make as little effort as possible to update the field, when needed.
>> 
>> Moreover, it has been implemented a new method for testing wheter a bit set includes another bit set (i.e., the set of true bits of the parameter is a subset of the true bits of the instance).
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added author and reverse the cicle order in includes(BitSet)

Libraries cannot be all things to all users. A library provides a service that would be difficult for a majority of users to implement on their own. Sometimes a library needs specialization for certain use cases. That is why we use subclassing and wrappers to extend existing libraries.

I think you will find that most BitSet users (including the JDK itself) want basic bit operations with a minimal overhead. If there was additional overhead, many would then roll their own versions to avoid that overhead. We have conflicting goals.

BitSet has served all JDK users well since JDK 1.0. I think your concerns are valid, but better cardinality would be best implemented as a subclass (CardinalBitSet?) of BitSet. Once constructed, you could then propose the addition to java.util with a CSR. 

If you want to make a case for `includes(BitSet)` that should be proposed as a separate CSR.

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

PR: https://git.openjdk.org/jdk/pull/11837