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
