On Mon, 7 Jun 2021 18:46:11 GMT, Naoto Sato wrote:
>> @mkartashev thank you for the detailed explanation.
>>
>> It is not clear to me that the JDK's conformance to being a Unicode
>> application has significantly changed since the evaluation of JDK-8017274 -
>> @naotoj can you comment on tha
On Sun, 6 Jun 2021 22:25:44 GMT, David Holmes wrote:
>> I think we need to establish some common ground before proceeding further
>> with this fix. It's a bit of a long read; please, bear with me.
>>
>> The path name starts its life as a `jstring` in
>> `Java_jdk_internal_loader_NativeLibrarie
On Fri, 4 Jun 2021 13:36:27 GMT, Maxim Kartashev
wrote:
>> Character strings within JVM are produced and consumed in several formats.
>> Strings come from/to Java in the UTF8 format and POSIX APIs (like fprintf()
>> or dlopen()) consume strings also in UTF8. On Windows, however, the
>> situat
On Sun, 6 Jun 2021 22:25:44 GMT, David Holmes wrote:
>> I think we need to establish some common ground before proceeding further
>> with this fix. It's a bit of a long read; please, bear with me.
>>
>> The path name starts its life as a `jstring` in
>> `Java_jdk_internal_loader_NativeLibrarie
On Fri, 4 Jun 2021 14:00:25 GMT, Maxim Kartashev
wrote:
>> Not an expert by my understanding is that the VM only deals with modified
>> UTF-8, as does JNI. So the incoming string should be modified-UTF8 IMO and
>> then converted to UTF16.
>>
>> That said, this is shared code being modified on
On Fri, 4 Jun 2021 13:36:27 GMT, Maxim Kartashev
wrote:
>> Character strings within JVM are produced and consumed in several formats.
>> Strings come from/to Java in the UTF8 format and POSIX APIs (like fprintf()
>> or dlopen()) consume strings also in UTF8. On Windows, however, the
>> situat
On Fri, 4 Jun 2021 14:00:25 GMT, Maxim Kartashev
wrote:
>> Not an expert by my understanding is that the VM only deals with modified
>> UTF-8, as does JNI. So the incoming string should be modified-UTF8 IMO and
>> then converted to UTF16.
>>
>> That said, this is shared code being modified on
On Fri, 4 Jun 2021 02:12:42 GMT, David Holmes wrote:
>> I am not sure we can pass non `modified UTF-8` through `JVM_LoadLibrary()`.
>> Probably some VM folks can enlighten here?
>
> Not an expert by my understanding is that the VM only deals with modified
> UTF-8, as does JNI. So the incoming s
> Character strings within JVM are produced and consumed in several formats.
> Strings come from/to Java in the UTF8 format and POSIX APIs (like fprintf()
> or dlopen()) consume strings also in UTF8. On Windows, however, the situation
> is far less simple: some new(er) APIs expect UTF16 (wide-ch
On Thu, 3 Jun 2021 17:51:54 GMT, Naoto Sato wrote:
> I think we can simply limit the test platform only to Windows in @requires
> tag in the test. Also, I would see the test case using some supplementary
> characters.
Done.
-
PR: https://git.openjdk.java.net/jdk/pull/4169
On Thu, 3 Jun 2021 17:48:59 GMT, Naoto Sato wrote:
>> Right; I changed the code in NativeLibraries.c to pass down true UTF-8
>> instead of "modified UTF-8". Please, take a look.
>
> I am not sure we can pass non `modified UTF-8` through `JVM_LoadLibrary()`.
> Probably some VM folks can enlighte
On Thu, 3 Jun 2021 06:59:01 GMT, Maxim Kartashev
wrote:
>> test/hotspot/jtreg/runtime/jni/loadLibraryUnicode/LoadLibraryUnicodeTest.java
>> line 42:
>>
>>> 40: String nativePathSetting = "-Dtest.nativepath=" +
>>> getSystemProperty("test.nativepath");
>>> 41: ProcessBuilder pb
On Thu, 3 Jun 2021 06:55:26 GMT, Maxim Kartashev
wrote:
>> src/hotspot/os/windows/os_windows.cpp line 1491:
>>
>>> 1489: static errno_t convert_UTF8_to_UTF16(char const* utf8_str, LPWSTR*
>>> utf16_str) {
>>> 1490: return convert_to_UTF16(utf8_str, CP_UTF8, utf16_str);
>>> 1491: }
>>
>> IIU
On Tue, 1 Jun 2021 18:42:34 GMT, Naoto Sato wrote:
>> Maxim Kartashev has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Coding style-related corrections.
>> - Corrected the test to use Platform.sharedLibraryExt()
>
> test/hotspot/jtreg/
On Tue, 1 Jun 2021 18:24:05 GMT, Naoto Sato wrote:
>> Maxim Kartashev has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Coding style-related corrections.
>> - Corrected the test to use Platform.sharedLibraryExt()
>
> src/hotspot/os/wind
> Character strings within JVM are produced and consumed in several formats.
> Strings come from/to Java in the UTF8 format and POSIX APIs (like fprintf()
> or dlopen()) consume strings also in UTF8. On Windows, however, the situation
> is far less simple: some new(er) APIs expect UTF16 (wide-ch
On Thu, 27 May 2021 16:14:38 GMT, Maxim Kartashev
wrote:
>> Character strings within JVM are produced and consumed in several formats.
>> Strings come from/to Java in the UTF8 format and POSIX APIs (like fprintf()
>> or dlopen()) consume strings also in UTF8. On Windows, however, the
>> situa
On Fri, 28 May 2021 05:47:11 GMT, David Holmes wrote:
> The core-libs folks have the experience/expertise with these character
> encoding issues so I will defer to them.
Naoto has agreed to look at this.
-
PR: https://git.openjdk.java.net/jdk/pull/4169
On Thu, 27 May 2021 16:28:14 GMT, Maxim Kartashev
wrote:
>> src/hotspot/os/windows/os_windows.cpp line 1541:
>>
>>> 1539: void * os::dll_load(const char *utf8_name, char *ebuf, int ebuflen) {
>>> 1540: LPWSTR utf16_name = NULL;
>>> 1541: errno_t err = convert_UTF8_to_UTF16(utf8_name, &utf16
On Thu, 27 May 2021 05:13:44 GMT, David Holmes wrote:
>> Maxim Kartashev has refreshed the contents of this pull request, and
>> previous commits have been removed. The incremental views will show
>> differences compared to the previous content of the PR. The pull request
>> contains one new c
On Thu, 27 May 2021 05:18:50 GMT, David Holmes wrote:
>> Maxim Kartashev has refreshed the contents of this pull request, and
>> previous commits have been removed. The incremental views will show
>> differences compared to the previous content of the PR. The pull request
>> contains one new c
On Thu, 27 May 2021 04:23:16 GMT, David Holmes wrote:
>> Maxim Kartashev has refreshed the contents of this pull request, and
>> previous commits have been removed. The incremental views will show
>> differences compared to the previous content of the PR. The pull request
>> contains one new c
> Character strings within JVM are produced and consumed in several formats.
> Strings come from/to Java in the UTF8 format and POSIX APIs (like fprintf()
> or dlopen()) consume strings also in UTF8. On Windows, however, the situation
> is far less simple: some new(er) APIs expect UTF16 (wide-ch
On Tue, 25 May 2021 09:45:34 GMT, Maxim Kartashev
wrote:
>> Character strings within JVM are produced and consumed in several formats.
>> Strings come from/to Java in the UTF8 format and POSIX APIs (like fprintf()
>> or dlopen()) consume strings also in UTF8. On Windows, however, the
>> situa
On Tue, 25 May 2021 09:45:34 GMT, Maxim Kartashev
wrote:
>> Character strings within JVM are produced and consumed in several formats.
>> Strings come from/to Java in the UTF8 format and POSIX APIs (like fprintf()
>> or dlopen()) consume strings also in UTF8. On Windows, however, the
>> situa
On 27/05/2021 6:59 am, Gerard Ziemski wrote:
On Tue, 25 May 2021 09:45:34 GMT, Maxim Kartashev
wrote:
I tried verifying the test on **macOS** by running:
`jtreg -nr -va -jdk:./build/macosx-x86_64-server-fastdebug/images/jdk
test/hotspot/jtreg/runtime/jni/loadLibraryUnicode`
and I get:
`TEST
On Tue, 25 May 2021 09:45:34 GMT, Maxim Kartashev
wrote:
>> Character strings within JVM are produced and consumed in several formats.
>> Strings come from/to Java in the UTF8 format and POSIX APIs (like fprintf()
>> or dlopen()) consume strings also in UTF8. On Windows, however, the
>> situa
> Character strings within JVM are produced and consumed in several formats.
> Strings come from/to Java in the UTF8 format and POSIX APIs (like fprintf()
> or dlopen()) consume strings also in UTF8. On Windows, however, the situation
> is far less simple: some new(er) APIs expect UTF16 (wide-ch
On Mon, 24 May 2021 16:43:09 GMT, Maxim Kartashev
wrote:
> Character strings within JVM are produced and consumed in several formats.
> Strings come from/to Java in the UTF8 format and POSIX APIs (like fprintf()
> or dlopen()) consume strings also in UTF8. On Windows, however, the situation
>
Character strings within JVM are produced and consumed in several formats.
Strings come from/to Java in the UTF8 format and POSIX APIs (like fprintf() or
dlopen()) consume strings also in UTF8. On Windows, however, the situation is
far less simple: some new(er) APIs expect UTF16 (wide-character
30 matches
Mail list logo
