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

Anthony Vanelverdinghe anthonyv.be at outlook.com
Fri Sep 14 17:16:51 UTC 2018

Thanks for the status update and insightful details, Sherman, they’re much appreciated.

Kind regards,


From: core-libs-dev <core-libs-dev-bounces at openjdk.java.net> on behalf of Xueming Shen <xueming.shen at oracle.com>
Sent: Friday, September 14, 2018 12:38:28 AM
To: core-libs-dev at openjdk.java.net
Subject: Re: JDK-8124977: deadlock between engineers? (cmdline encoding challenges on Windows)

On 9/13/18, 3:36 PM, Xueming Shen wrote:
> Anthony,
> 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 sun.jnu.encoding
> to be always "utf8", is incomplete and incorrect (see my comment [3]
> for why).

oops, there is one sentence is missing here :-

There are three system properties inside jvm to deal with this "native
encoding" issue:

> file.encoding: how to interpret, by default, the content in/from the
> outside of the vm, file, socket
>                      for example
> sun.jnu.encoding:
>                      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.
> sun.stdout/err.encoding:
>                      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
> alternative/
> 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.
> Thanks,
> Sherman
> [1]
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-February/039070.html
> [2] http://cr.openjdk.java.net/~kshoop/8124977/webrev.05/
> [3]
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-February/039068.html
> 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