JDK-8124977: deadlock between engineers? (cmdline encoding challenges on Windows)
xueming.shen at oracle.com
Thu Sep 13 22:36:37 UTC 2018
I don't see/recall there was any response to my last review comment .
change in webrev.05 , in which it forces the internal system property
to be always "utf8", is incomplete and incorrect (see my comment  for
file.encoding: how to interpret, by default, the content in/from the
outside of the vm, file, socket
how to talk to the platform APIs, on Windows
platform for example, how to
to de/encoding the bytes to/from the Win32 "A"
version of APIs, for example
CreateFileA(char* fname....). It's also used to
"interpret" the bytes in those
char* of the interface between jvm and libraries.
how to talk to the "console" when you output to
the std err/out when
the std in/out is linked the a real console/term
So the bottom line is that you can't just simply override
sun.jnu.encoding to utf8 on windows
before we either migrate all our "A" version win32 system call to "W"
(do autf8->utf16) or
to put yet another layer there to convert "utf8->mb" before calling the
"A" version win32.
An alternative is to limit the scope of the problem, to only have some
workaround solution for the arguments passed to Java main class. For
example to do something
in libjli/java_md.c/CreateApplicationArgs() when decoding the char* to
LauncherHelper.makePaltformString(...), which uses sun.jnu.encoding now.
(my guess is
this is where the idea of overwriting sun.jnu.encoding comes from).
Currently I don't think there is anyone from Oracle actively working on
this issue. I'm not
sure if engineer from Microsoft is still working on it.
On 9/12/18, 10:29 AM, Anthony Vanelverdinghe wrote:
> What is the status of this issue ? It addresses some long-standing issues with Java's Unicode support on Windows and was contributed by a team of Microsoft engineers. However, it seems to have gone dormant right before the finish line, and I can't really figure out who's waiting for whom at this point.
> A little reconstruction from what I could find:
> In January 2015, Martin Sawicki made the initial proposal to address the cmdline encoding challenges on Windows 
> From June to September, there were ongoing discussions 
> In November, this was shortly picked up again by the Oracle engineers 
> In January 2016, after a ping by a Microsoft engineer, the discussions restarted 
> In February 2016, the patch seemed nearly ready for integration, with an Oracle engineer asking whom to mention as contributors etc. 
> Since then, I was unable to find any messages related to this issue
> (Personally, I would love to see this issue progress, in order to be able to associate Java programs with file extensions on Windows. This is currently problematic, since a file containing Unicode characters will not get passed correctly as an argument to the Java program)
> Kind regards,
>  https://bugs.openjdk.java.net/browse/JDK-8124977
>  http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-January/031068.html
>  http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-June/034226.html
>  http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-July/034488.html
>  http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-August/034838.html
>  http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-September/035466.html
>  http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-November/036769.html
>  http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-January/037927.html
>  http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-February/039013.html
More information about the core-libs-dev