Thanks for the status update and insightful details, Sherman, they’re much appreciated.
Kind regards, Anthony ________________________________ From: core-libs-dev <core-libs-dev-boun...@openjdk.java.net> on behalf of Xueming Shen <xueming.s...@oracle.com> Sent: Friday, September 14, 2018 12:38:28 AM To: core-libs-dev@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 >
