Make BloomFilter.bitSize() public

[nickita-khylkouski]

Summary

This PR makes the existing bitSize() method in BloomFilter public. Previously it was package-private with @VisibleForTesting.

Motivation

Users who embed Bloom filters in custom file formats need to know the serialization size before writing to pre-allocate space (e.g., for memory-mapped files or fixed-size records). Currently the only way to determine the size is to actually serialize the filter, which is inefficient.

Changes

• Changed bitSize() visibility from package-private to public
• Removed @VisibleForTesting annotation
• Added comprehensive Javadoc explaining:
  • The method's purpose
  • How to calculate serialization size: bitSize() / 8 + 6 bytes
  • The 6-byte header breakdown (1 byte strategy, 1 byte hash functions, 4 bytes array length)
• Added @since 35.0 annotation
• Applied changes to both JRE and Android flavors

Tests

Added testBitSizeMatchesSerializationSize() test that verifies bitSize() correctly predicts the writeTo() output size across various configurations.

Test plan

• New test testBitSizeMatchesSerializationSize() validates the size calculation formula
• Existing testBitSize() test continues to pass (now testing public API)
• Run full Guava test suite

Fixes #6866

[kluever]

I wonder if it'd be more convenient for users if we exposed an API that tells you how many bytes (instead of bits) the underlying AtomicLongArray is? We'd want to figure out a good name for it (I'm not convinced byteSize() is very good :-)

[jrtom]

waves

I'm not convinced that byteSize() is the best name, but at least it's easily digestible. ;)

More serially seriously: I do agree that providing the size in bytes is better than the size in bits, at least for the proposed purpose. That said: if the sole purpose of providing it is to inform serialization users of the size of the object to be serialized, maybe the reported size should both (a) be in bytes and (b) include the header as well, and be named something like serializationSize().

[nickita-khylkouski]

Great suggestions! I agree — returning bytes with the header included is a cleaner API. Users shouldn't need to do the bitSize() / 8 + 6 math themselves.

For naming, a few options:

• serializationSize() — @jrtom's suggestion, clean and direct
• serializedSizeInBytes() — explicit about units, but verbose
• writtenSize() — ties to writeTo(), but less clear in isolation

I lean toward serializationSize() for simplicity. Happy to update the PR once you settle on a name — or if you'd prefer a different approach entirely.