On 10/27/2015 1:18 PM, Anton Litvinov wrote:
Hello,
Could you please review the following fix for the bug.
Bug: https://bugs.openjdk.java.net/browse/JDK-8132503
Webrev: http://cr.openjdk.java.net/~alitvinov/8132503/jdk9/webrev.00
The bug consists in the fact that after the fix for JDK-8068283, when
IDEOGRAPHIC FULL STOP character "。" is entered from a keyboard using
Pinyin IM, "java.awt.event.InputMethodEvent" is not generated and FULL
STOP character "." is entered in "javax.swing.JTextArea" component.
The solution adds the additional check to "if" condition, which was
edited by the fix for JDK-8068283,
"if ([self hasMarkedText] || !fProcessingKeystroke || (utf16Length >
2)) {"
in the method "- (void) insertText:(id) replacementRange:(NSRange)"
from the file
"jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/AWTView.m". This
additional check defines, whether the analyzed code point belongs to
Unicode code points range "U+3000 – U+303F" ("CJK Symbols and
Punctuation"), which contains "。" character and, if it is so,
generates "InputMethodEvent".
It was interested for me does Cocoa or Java allow to get a minimal
and maximal character for the given Unicode Block.
I was not able to find how to do it in Cocoa.
Java has an open RFE JDK-7057645 Add methods to
Character.UnicodeBlock (returning first & last codepoints, the list of
blocks).
May be the current issue can be one more valid use case for the RFE.
I have just few comments:
- aString is treated as NSString. Can it have more than one Unicode
character?
- It could be better to move the check that a unichar belongs to a
separate function that can be easily extended later for new Unicode Blocks.
Thanks,
Alexandr.
It was verified in a local environment that the regression test from
the fix for JDK-8068283 does not fail with this fix also.
Thank you,
Anton
