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.s...@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
