On Sat, 15 Aug 2026 15:42:01 GMT, Alan Bateman <[email protected]> wrote:
>> I have now added a check that will execute the fast-path optimization only >> in the REPLACE case, and only with the very same charset decoder class. > > I don't think this is quite right. A CharsetDecoder can be configured with a > "replacement value" so it may be different than the default. If someone > creates an InputStreamReader with a configured CharsetDecoder then the > proposed fast path will use the String constructor and the default > replacement value, oops! > > The slow path looks like it has an issue too. The decoder needs to be reset > at EOF, otherwise a subsequent read will throw rather than return -1. Look at > the existing implRead implementation to see what I mean. > > It might be simpler to reduce the focus of the proposal to only the cases > where an InputStreamReader is created with a Charset and no characters are > read from the reader before readAsString is invoked to consume to EOF. Leave > all other cases to the existing code. Given the land mines, maybe it would be better to park this PR and focus first on adding tests for corner cases. These tests will be needed anyway to be confident with any re-implementation or changes to this code. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/32264#discussion_r3789938046
