JEP proposed to target JDK 18: 400: UTF-8 by Default
Alan Bateman
Alan.Bateman at oracle.com
Thu Aug 19 06:40:13 UTC 2021
On 18/08/2021 22:44, Naoto Sato wrote:
> On 8/18/21 2:03 PM, Simon Nash wrote:
>> I am the developer of a fairly large application that uses file I/O
>> extensively. In most cases, the charset should be UTF-8 and I have
>> used an explicit charset parameter on all method invocations where
>> this applies. In some cases, the charset needs to be the platform
>> default charset to produce output that is readable by other programs
>> or by a user (for example, Windows-1252 on some versions of Windows).
>>
>> In the cases that need the platform default charset, I have omitted
>> the charset (intentionally, not carelessly or accidentally). If the
>> behaviour changes in these cases, it will produce unexpected results
>> for users.
>
> In preparation for JEP 400, we have provided a new system property
> that retrieves the native encoding name in JDK17:
>
> https://bugs.openjdk.java.net/browse/JDK-8265989
>
> Apps that have luxury to make code base change can use the property to
> retrieve the native encoding, then use it to replace no-arg I/O
> constructors to the explicit equivalent ones.
Yes, if there is code that really wants to use the native encoding and
run of wide range of JDK releases without the using COMPAT then it can
read the value of native.encoding and use Charset.defaultCharset if the
property is not set.
-Alan.
More information about the core-libs-dev
mailing list