garydgregory commented on PR #776: URL: https://github.com/apache/commons-io/pull/776#issuecomment-3264154631
> Hi @garydgregory, > > I’ve refactored this proposal a bit further: > > * Extended chunked reading to the legacy `toByteArray(InputStream, int/long)` methods as well. > * Revised the Javadoc to clarify the contract. As you mentioned earlier, we should **not** guide users based on how _trusted_ the size parameter is. I’ve also removed explicit references to `OutOfMemoryError`, which can always occur. Instead, the docs now emphasize that memory allocation is **proportional to the number of bytes actually read** (previously it was _de facto_ proportional to the `size` argument). > > Open questions: > > * **Chunking threshold**: Currently set to 128 KiB, matching CPython. JDK 11+ uses 16 KiB. We could also consider raising our default buffer size (currently 8 KiB, and in some places as low as 1 KiB, which feels outdated). > * **Use of `available()`**: Should we consult `available()` in `toByteArray(InputStream, int)` and `toByteArray(InputStream)` (see [feat: Add incremental `toByteArray` method #776 (comment)](https://github.com/apache/commons-io/pull/776#discussion_r2326598113))? The `toByteArray(InputStream, int, int)` method explicitly promises chunks up to `chunkSize`, but the others do not. CPython is irrelevant IMO. Java's `Files.BUFFER_SIZE` class in Java 21 is 8K, so 8K is consistent as the default. > JDK 11+ uses 16 KiB. Where do you see that? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
