Inconsistencies when creating a Reader from a Path
Alan.Bateman at oracle.com
Fri Feb 28 07:57:23 UTC 2020
On 27/02/2020 19:33, Norbert Kiesel wrote:
> Which brings me to my questions:
> 1. Should the 2 approaches not behave identical by default?
> 2. Is there a way to use the first approach but end up with the same error
> behavior as the second approach? One possible way would be to create an
> overloaded `Files.newBufferedReader` which takes a `CharsetDecoder` as
> second parameter.
The java.io APIs mostly date from early JDK releases. Changing
InputStreamReader to report errors with malformed input or unmappable
characters would be an incompatible change. Yes, replacing erroneous
input with a replacement value can be surprising in some usages. I think
we should at least improve the documentation of the APIs that bridge
between byte and character streams. The Files.newBufferedReader factory
method was intended to avoid surprises. It uses UTF-8 by default (not
the default charset) and is specified to return a Reader that throws
when malformed input or unmappable is encountered. Yes, a variant that
takes a CharsetDecoder could be added but that is an advanced API so the
method would only save one line of code for someone that has a
CharsetDecoder. Best to follow up on core-libs-dev, I think we should at
least improve the javadoc in a number of places.
More information about the jdk-dev