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

[Volker Simonis]

Hi Sherman,

the tricky part is really "sun.jnu.encoding" and how the VM interacts
with the underlying OS. You may remember that we had an interesting
discussion about this topic some time ago [1].

As far as I understand, the JEP doesn't plan to change the handling of
"sun.jnu.encoding". So does this mean that the VM will still correctly
start and work on system with a platform encoding different from
UTF-8? I.e. will starting the VM from a path which contains characters
in that special platform encoding or classpath/argument settings with
characters in that special character encoding still work? If the
answer will be yes (which I expect) maybe you could explain that a
little more detailed in the JEP. I.e. the JEP should say that it
changes the default encoding for the Java API classes and not the
default encoding for natively accessing system resources.

Maybe the JEP should also mention that "sun.jnu.encoding" is more or
less a "read-only" property which can not be reliable set by the user
on the command line (it's a chicken-egg problem: for the parsing of
the command line we need the correct encoding, so it can not be
reliably set on the command line).

For these reasons the Summary "Use UTF-8 as the Java virtual machine's
default charset ..." is a little misleading. Maybe you could rephrase
to something like "Use UTF-8 as the default charset so that Java APIs
that depend on the default charset behave consistently across all
platforms."

Thank you and best regards,
Volker

[1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-December/thread.html#37516

On Wed, Feb 21, 2018 at 7:31 AM, Xueming Shen <xueming.shen at oracle.com> wrote:
> This draft JEP contains a proposal to use UTF-8 as the default charset for
> the JVM, so that
> APIs that depend on the default charset behave consistently cross all
> platforms.
>
> For more details, please see:
> https://bugs.openjdk.java.net/browse/JDK-8187041
>
> Sherman