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.
