RFR JDK-8200243: System error message is decoded as invalid encoding in Windows.
Hi, Please help review the change for JDK-8200243 issue: https://bugs.openjdk.java.net/browse/JDK-8200243 webrev: http://cr.openjdk.java.net/~sherman/8200243/webrev This is a regression. The root cause is one of the change we put in jdk9 for JDK-8057777 [1], which is to remove those unused vm interfaces. The webrev [1] indicates that the changeset added a platform dependent version of GetLastErrorString(), which uses utf8, to replace the original jvm version of JVM_GetLastErrorString() (in jni_util.c). However the encoding of the char* interface between jvm and jdk is always interpreted/specified as "native encoding". So if the platform's default encoding is NOT utf-8, it never uses utf8. This is what we have on Windows platform. The fix is to use/copy-paste the "original" vm implementation in hotspot repo for JVM_GetLastErrorString() (from os_windows.cpp). The fix has been verified on a Chinese version of windows. Thanks Felix! Thanks, Sherman [1] https://bugs.openjdk.java.net/browse/JDK-8057777
On 27/06/2018 04:14, Xueming Shen wrote:
Hi,
Please help review the change for JDK-8200243
issue: https://bugs.openjdk.java.net/browse/JDK-8200243 webrev: http://cr.openjdk.java.net/~sherman/8200243/webrev
This is a regression. The root cause is one of the change we put in jdk9 for JDK-8057777 [1], which is to remove those unused vm interfaces.
The webrev [1] indicates that the changeset added a platform dependent version of GetLastErrorString(), which uses utf8, to replace the original jvm version of JVM_GetLastErrorString() (in jni_util.c).
However the encoding of the char* interface between jvm and jdk is always interpreted/specified as "native encoding". So if the platform's default encoding is NOT utf-8, it never uses utf8. This is what we have on Windows platform. The fix is to use/copy-paste the "original" vm implementation in hotspot repo for JVM_GetLastErrorString() (from os_windows.cpp). This looks okay, just not immediately clear if this links to FormatMessageA or FormatMessageW.
-Alan
On 6/27/18, 12:39 AM, Alan Bateman wrote:
On 27/06/2018 04:14, Xueming Shen wrote:
Hi,
Please help review the change for JDK-8200243
issue: https://bugs.openjdk.java.net/browse/JDK-8200243 webrev: http://cr.openjdk.java.net/~sherman/8200243/webrev
This is a regression. The root cause is one of the change we put in jdk9 for JDK-8057777 [1], which is to remove those unused vm interfaces.
The webrev [1] indicates that the changeset added a platform dependent version of GetLastErrorString(), which uses utf8, to replace the original jvm version of JVM_GetLastErrorString() (in jni_util.c).
However the encoding of the char* interface between jvm and jdk is always interpreted/specified as "native encoding". So if the platform's default encoding is NOT utf-8, it never uses utf8. This is what we have on Windows platform. The fix is to use/copy-paste the "original" vm implementation in hotspot repo for JVM_GetLastErrorString() (from os_windows.cpp). This looks okay, just not immediately clear if this links to FormatMessageA or FormatMessageW.
Without an explicit _UNICODE and UNICODE switch it should always be "A" version. If we have more time maybe I should go through the circle to simply use the "A" explicitly. -Sherman
participants (2)
-
Alan Bateman
-
Xueming Shen