What I meant by that is the "porting" part of the code, not the Apple
JDK itself. IIRC, the initial porting from Apple JDK to Oracle JDK was
done by folks at Apple, and that piece of comment was included since the
initial port:
https://bugs.openjdk.java.net/browse/JDK-7113349
Naoto
On 12/12/14, 3:07 AM, Sergey Malenkov wrote:
I'm not sure that this is the Apple's code, because Oracle JDK works
slightly different from Apple JDK.
On Fri, Dec 12, 2014 at 12:04 AM, Naoto Sato <naoto.s...@oracle.com> wrote:
Honestly I cannot judge whether that is OK or not, because I don't know the
original intention of the comment I quoted in the previous mail. Maybe there
were some corner cases and that's what I wanted to know. Maybe asking the
original authors of the code (at Apple?) about this would help?
Naoto
On 12/11/14 3:15 AM, Sergey Malenkov wrote:
Hi Naoto,
I think it may affect some Chinese symbols, which are represented by 2
Java-characters, but I don't have a corresponding keyboard to check. I
could modify the fix: create jstring before the if-statement and check
for its length. This looks safe and helps to determine a complex (in
Java terms) Unicode value. What do you think?
On Wed, Dec 10, 2014 at 10:21 PM, Naoto Sato <naoto.s...@oracle.com>
wrote:
Hi Sergey,
It seems that the comment specifically mentions to go this route "when
the
string to insert is a complex Unicode value." and your change would break
it. Have you investigated what it means?
Also, if the change turns OK, you probably would want to change the
variable
name from "utf8Length" to something more appropriate.
Naoto
On 12/10/14, 9:56 AM, Sergey Malenkov wrote:
Hi all,
In Oracle JDK the input method handling is slightly different from
Apple JDK. And this is a reason of some issues in IntelliJ IDEA. I
found out that the insertText method in the following file uses
lengthOfBytesUsingEncoding instead of length in characters:
http://hg.openjdk.java.net/jdk9/dev/jdk/file/e5b66323ae45/src/java.desktop/macosx/native/libawt_lwawt/awt/AWTView.m
This means that almost every Alt+Key combination generates
InputMethodEvent instead of pair of KeyEvent for PRESSED and TYPED. It
makes impossible to support custom shortcuts for all Alt+Key and
Shift+Alt+Key combinations on Mac, what is one of the reasons why
users do not want to migrate from Apple JDK to Oracle JDK on Mac.
I suggest to apply the following patch to the AWTView.m file:
--- a/src/macosx/native/sun/awt/AWTView.m Wed Dec 10 17:20:48 2014 +0400
+++ b/src/macosx/native/sun/awt/AWTView.m Wed Dec 10 19:51:56 2014 +0300
@@ -889,7 +889,7 @@
// text, or 'text in progress'. We also need to send the event
if we get an insert text out of the blue!
// (i.e., when the user uses the Character palette or Inkwell),
or when the string to insert is a complex
// Unicode value.
- NSUInteger utf8Length = [aString
lengthOfBytesUsingEncoding:NSUTF8StringEncoding];
+ NSUInteger utf8Length = [aString length];
if ([self hasMarkedText] || !fProcessingKeystroke || (utf8Length
1)) {
JNIEnv *env = [ThreadUtilities getJNIEnv];
It makes the input method handling more compatible with Apple JDK and
allows us to provide users the same behavior with Oracle JDK.
Do you have any objections?
Are there some hidden pitfalls?
