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

Xueming Shen xueming.shen at oracle.com
Thu Sep 13 22:38:28 UTC 2018


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