PARQUET-2357: Modest refactor of CapacityByteArrayOutputStream

[fengjiajie]

Optimization for the CapacityByteArrayOutputStream class:

1. The functionality of currentSlabIndex is the same as currentSlab.position(), so there is no need to maintain the currentSlabIndex variable.
2. When writing an array of length equal to the remaining capacity of the buffer, there is no need to expand to a new buffer.
3. If the addSlab operation has already implemented safeguards using Math.addExact to prevent overflow of bytesAllocated and bytesUsed, it is unnecessary to perform additional checks during the write operation.

Make sure you have checked all steps below.

Jira

• My PR addresses the following Parquet Jira issues and references them in the PR title. For example, "PARQUET-2357: Modest refactor of CapacityByteArrayOutputStream"
  • https://issues.apache.org/jira/browse/PARQUET-2357
  • In case you are adding a dependency, check if the license complies with the ASF 3rd Party License Policy.

Tests

• My PR adds the following unit tests OR does not need testing for this extremely good reason:

Commits

• My commits all reference Jira issues in their subject lines. In addition, my commits follow the guidelines from "How to write a good git commit message":
  1. Subject is separated from body by a blank line
  2. Subject is limited to 50 characters (not including Jira issue reference)
  3. Subject does not end with a period
  4. Subject uses the imperative mood ("add", not "adding")
  5. Body wraps at 72 characters
  6. Body explains "what" and "why", not "how"

Documentation

• In case of new functionality, my PR adds documentation that describes how to use it.
  • All the public functions and the classes in the PR contain Javadoc that explain what it does

[fengjiajie]

Hi, @Fokko

There is a test case failure, same one in another pull request(#1164). I think it may pass if re-run. However, I don't have the permission to trigger the run. I tried pushing again, but it didn't trigger a re-run.
Could you please take a look? Thank you very much.

2023-10-02T11:22:48.6797210Z [INFO] Results:
2023-10-02T11:22:48.6894266Z [INFO] 
2023-10-02T11:22:48.6895143Z [ERROR] Failures: 
2023-10-02T11:22:48.6895878Z [ERROR]   TestParquetWriter.testParquetFileWithBloomFilterWithFpp:342
2023-10-02T11:22:48.6896575Z [INFO] 
2023-10-02T11:22:48.6897791Z [ERROR] Tests run: 404, Failures: 1, Errors: 0, Skipped: 1

[wgtmac]

Hi, @Fokko

There is a test case failure, same one in another pull request(#1164). I think it may pass if re-run. However, I don't have the permission to trigger the run. I tried pushing again, but it didn't trigger a re-run. Could you please take a look? Thank you very much.

2023-10-02T11:22:48.6797210Z [INFO] Results:
2023-10-02T11:22:48.6894266Z [INFO] 
2023-10-02T11:22:48.6895143Z [ERROR] Failures: 
2023-10-02T11:22:48.6895878Z [ERROR]   TestParquetWriter.testParquetFileWithBloomFilterWithFpp:342
2023-10-02T11:22:48.6896575Z [INFO] 
2023-10-02T11:22:48.6897791Z [ERROR] Tests run: 404, Failures: 1, Errors: 0, Skipped: 1

This test case unfortunately employs a random number for generating bloom filter.