On 2/21/18, 6:26 AM, Robert Muir wrote:
On Wed, Feb 21, 2018 at 8:55 AM, Alan Bateman<alan.bate...@oracle.com> wrote:
Good progress was made via JDK-8183743 [1] in Java SE 10 to add constructors
and methods that take a Charset and eliminate the historical
inconsistencies. The issue of legacy FileReader/FileWriter is linked from
that JIRA issue.
Can we ensure we have CharsetDecoder/Encoder params too? There is
unfortunately a huge difference between InputStreamReader(x,
StandardCharsets.UTF_8) and InputStreamReader(x,
StandardCharsets.UTF_8.newDecoder()). And the silent replacement of
the "easier" one is probably not what most apps want.
Hi Robert,
Understood a silent replacement might not be the desired behavior in
some use scenarios. Anymore details regarding what "most apps want"
when there is/are malformed/unmappable? It appears the best the
underneath de/encoder can do here is to throw an IOException. Given
the caller of the Reader/Writer does not have the access to the bytes of
the underlying stream src (reader)/dst(writer), there is in theory
impossible
to do anything to recover and continue without risking data loss. The
assumption here is if you want to have a fine-grained control of the de/
encoding, you might want to work with the Input/OutStream/Channel +
CharsetDe/Encoder instead of Reader/Writer.
No, I'm not saying we can't do
Reader(CharsetDecoder)/Writer(CharsetEncoder),
just wanted to know what's the real use scenario and what's the better/
best choice here.
-Sherman
