On Mon, Nov 4, 2024 at 8:46 PM Naoto Sato <naoto.s...@oracle.com> wrote: > I am afraid that the risk that would be involved in configuring > sun.jnu.encoding exceeds the benefit it would bring, as the encoding is > so baked in the basis of the Windows Java runtime. Since Microsoft > itself now recommends users choose UTF-8 as the ANSI code page (over > changing apps to use -W APIs)[1], I think we would want to wait for that > glorious day. > > Naoto > > [1] > https://learn.microsoft.com/en-us/windows/apps/design/globalizing/use-utf8-code-page#-a-vs--w-apis
My understanding of that page is that Microsoft recommends *application developers* to choose UTF-8 as the code page for their apps by adding a directive to their app manifest. While this works well for native applications, it doesn't directly apply to Java applications as the manifest is that of the java.exe launcher binary, which is necessarily static (and currently doesn't set the `activeCodePage` directive). We could choose to rely on users switching to the UTF-8 codepage system-wide. This is possible as of the 1809 build of Windows 10, but is not the default, still marked as Beta in the latest version, requires admin privileges to enable, and can break other applications, even of other users. This may become the default some day, but it's unclear whether this will happen in the foreseeable future, especially since there is a backwards compatible alternative for native applications. I understand that incrementally refactoring the Windows Java runtime until its encoding becomes configurable is too risky. Taking that into account, what do you think of offering an additional entrypoint for the Java launcher on Windows, say java-utf8.exe, that is identical to java.exe except that it specifies `<activeCodePage>UTF-8</activeCodePage>` in its app manifest? This would give users the desired opt-in behavior with no changes to the actual implementation of the Java runtime. (In fact, in my concrete use case, we are relying on this as a workaround by patching the manifest in java.exe with a tool [1].) Fabian [1] https://github.com/bazelbuild/bazel/pull/24172/files#diff-a0c93cc3220759276f3c447b2fd213159d66612d2eb3b19173df20129625dd6a
