Draft JEP: To use UTF-8 as the default charset for the Java virtual machine.

[Xueming Shen]

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 [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