JDK-8124977: deadlock between engineers? (cmdline encoding challenges on Windows)

Xueming Shen 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 [1]. 
The proposed
change in webrev.05 [2], in which it forces the internal system property 
to be always "utf8", is incomplete and incorrect (see my comment [3] for 

file.encoding: how to interpret, by default, the content in/from the 
outside of the vm, file, socket
                      for example
                      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 
jstring via
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.


[2] http://cr.openjdk.java.net/~kshoop/8124977/webrev.05/

On 9/12/18, 10:29 AM, Anthony Vanelverdinghe wrote:
> Hi
> What is the status of this issue [1]? 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 [2]
>  From June to September, there were ongoing discussions [3][4][5][6]
> In November, this was shortly picked up again by the Oracle engineers [7]
> In January 2016, after a ping by a Microsoft engineer, the discussions restarted [8]
> In February 2016, the patch seemed nearly ready for integration, with an Oracle engineer asking whom to mention as contributors etc. [9]
> 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,
> Anthony
> [1] https://bugs.openjdk.java.net/browse/JDK-8124977
> [2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-January/031068.html
> [3] http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-June/034226.html
> [4] http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-July/034488.html
> [5] http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-August/034838.html
> [6] http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-September/035466.html
> [7] http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-November/036769.html
> [8] http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-January/037927.html
> [9] http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-February/039013.html

More information about the core-libs-dev mailing list