Draft JEP: To use UTF-8 as the default charset for the Java virtual machine.
xueming.shen at oracle.com
Wed Feb 21 18:16:40 UTC 2018
On 2/21/18, 6:26 AM, Robert Muir wrote:
> On Wed, Feb 21, 2018 at 8:55 AM, Alan Bateman<Alan.Bateman at oracle.com> wrote:
>> Good progress was made via JDK-8183743  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.
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
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
just wanted to know what's the real use scenario and what's the better/
best choice here.
More information about the core-libs-dev