Allowing apps to force sun.jnu.encoding = "UTF-8" on Windows

[Fabian Meumertzheim]

On Mon, Nov 4, 2024 at 8:46 PM Naoto Sato <naoto.sato at 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