JDK-8124977: deadlock between engineers? (cmdline encoding challenges on Windows)
xueming.shen at oracle.com
Thu Sep 13 22:38:28 UTC 2018
On 9/13/18, 3:36 PM, Xueming Shen wrote:
> I don't see/recall there was any response to my last review comment
> . The proposed
> change in webrev.05 , in which it forces the internal system
> property sun.jnu.encoding
> to be always "utf8", is incomplete and incorrect (see my comment 
> for why).
oops, there is one sentence is missing here :-
There are three system properties inside jvm to deal with this "native
> 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.
>  http://cr.openjdk.java.net/~kshoop/8124977/webrev.05/
> 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
More information about the core-libs-dev