On Thu, 19 Aug 2021 21:05:46 GMT, Sergey Bylokhov <s...@openjdk.org> wrote:
>> When Ctrl+Space is pressed mac generates a string that contains the single >> unicode code point zero. >> The fn that converts it from an NSString to a Java String is using >> NewStringUTF. >> The input to that is a null terminated string which also has zero as the >> code point it contains, so >> we actually end up with a zero length Java string instead of the intended >> one code point in length. >> So the fix is to change the way we convert the string. >> >> There's an existing test CtrlAscii.java which sort of tests some of this but >> it isn't asserting that you >> get what you expect, its mostly testing you don't get something *unexpected* >> .. it will happily pass if >> you don't get keyevents. I did not want to change the purpose of that test >> for this. >> So I wrote a test specific to this Ctrl+Space to verify the fix but also ran >> all the standard automated tests too. > > src/java.desktop/macosx/native/libosxapp/JNIUtilities.m line 47: > >> 45: return NULL; >> 46: } >> 47: jstring jStr = (*env)->NewStringUTF(env, [str UTF8String]); > > Probably we should cleanup all usage of [nsstring UTF8String] in the code at > some point. Depends on what the source data is. FWIW in the macOS code in java.desktop there are just 5 others and none of them were touched/added/changed by the JNF work. They are all pre-existing. ------------- PR: https://git.openjdk.java.net/jdk/pull/5177
