From michael.fang at oracle.com Tue Dec 9 04:45:00 2014 From: michael.fang at oracle.com (Michael Fang) Date: Mon, 08 Dec 2014 20:45:00 -0800 Subject: [8u40] Review request for 8065069: jdk8u40 l10n resource file translation update 2 In-Reply-To: <54760C2D.6040903@oracle.com> References: <5474D68F.8030701@oracle.com> <547562F3.2040106@oracle.com> <54760C2D.6040903@oracle.com> Message-ID: <54867E4C.7080004@oracle.com> Hi Masayoshi, Thanks for the review. I decided to withdraw the proposed change in order to prevent the regression in sorting order. thanks, -michael On 14?11?26? 09:21 ??, Michael Fang wrote: > Hi Masayoshi, > > Thank you for your review comment. This was a regular translation > update from translation team for each release. Typically if they > change the translation, it's either to improve glossary consistency or > improve translation quality/accuracy. > > I am discussing with translation team whether we should keep existing > translation. > > thanks, > > -michael > > On 14?11?25? 09:19 ??, Masayoshi Okutsu wrote: >> Hi Michael, >> >> What's the reason to make the change? A drawback of the change would >> be that the Chinese locale names are no longer grouped together when >> the locale names are sorted in ja locale. The following are the old >> and new names sorted in ja locale. >> >> old: >> ??? >> ??? >> ???(???) >> ???(???) >> ??? >> >> new: >> ?????? >> ??? >> ??? >> ??? >> ?????? >> >> Masayoshi >> >> On 11/26/2014 4:20 AM, Michael Fang wrote: >>> Hi, >>> >>> Please help to code review the changes for the following CR: >>> 8065069: jdk8u40 l10n resource file translation update 2 >>> https://bugs.openjdk.java.net/browse/JDK-8065069 >>> >>> The webrev is located at: >>> http://cr.openjdk.java.net/~mfang/8065069/ >>> >>> thanks, >>> >>> -michael >> From michael.fang at oracle.com Wed Dec 10 03:12:39 2014 From: michael.fang at oracle.com (Michael Fang) Date: Tue, 09 Dec 2014 19:12:39 -0800 Subject: [8u40] Review request for 8065157: jdk8u40 Japanese man page file translation update Message-ID: <5487BA27.8000802@oracle.com> Hi, Please help to code review the changes for the following CR: 8065157: jdk8u40 Japanese man page file translation update https://bugs.openjdk.java.net/browse/JDK-8065157 The webrev is located at: http://cr.openjdk.java.net/~mfang/8065157/webrev.00/ It's only done for 8u40 and is not ported back from 9. thanks, -michael From naoto.sato at oracle.com Wed Dec 10 16:58:58 2014 From: naoto.sato at oracle.com (Naoto Sato) Date: Wed, 10 Dec 2014 08:58:58 -0800 Subject: [8u40] Review request for 8065157: jdk8u40 Japanese man page file translation update In-Reply-To: <5487BA27.8000802@oracle.com> References: <5487BA27.8000802@oracle.com> Message-ID: <54887BD2.7050200@oracle.com> Looks good to me. Naoto On 12/9/14, 7:12 PM, Michael Fang wrote: > Hi, > > Please help to code review the changes for the following CR: > 8065157: jdk8u40 Japanese man page file translation update > https://bugs.openjdk.java.net/browse/JDK-8065157 > > The webrev is located at: > http://cr.openjdk.java.net/~mfang/8065157/webrev.00/ > > It's only done for 8u40 and is not ported back from 9. > > thanks, > > -michael From michael.fang at oracle.com Wed Dec 10 17:05:52 2014 From: michael.fang at oracle.com (Michael Fang) Date: Wed, 10 Dec 2014 09:05:52 -0800 Subject: [8u40] Review request for 8065157: jdk8u40 Japanese man page file translation update In-Reply-To: <54887BD2.7050200@oracle.com> References: <5487BA27.8000802@oracle.com> <54887BD2.7050200@oracle.com> Message-ID: <54887D70.8040705@oracle.com> Thank you Naoto for the review. -michael On 14?12?10? 08:58 ??, Naoto Sato wrote: > Looks good to me. > > Naoto > > On 12/9/14, 7:12 PM, Michael Fang wrote: >> Hi, >> >> Please help to code review the changes for the following CR: >> 8065157: jdk8u40 Japanese man page file translation update >> https://bugs.openjdk.java.net/browse/JDK-8065157 >> >> The webrev is located at: >> http://cr.openjdk.java.net/~mfang/8065157/webrev.00/ >> >> It's only done for 8u40 and is not ported back from 9. >> >> thanks, >> >> -michael From malenkov at gmail.com Wed Dec 10 17:56:21 2014 From: malenkov at gmail.com (Sergey Malenkov) Date: Wed, 10 Dec 2014 20:56:21 +0300 Subject: The input method handling Message-ID: 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? -- Best regards, Sergey A. Malenkov JetBrains From ebakke at mit.edu Wed Dec 10 18:26:28 2014 From: ebakke at mit.edu (Eirik Bakke) Date: Wed, 10 Dec 2014 18:26:28 +0000 Subject: The input method handling In-Reply-To: References: Message-ID: Passing by--maybe the following piece of NetBeans Platform documentation has relevance: http://wiki.netbeans.org/DevFaqLogicalKeybindings Quote: "There should be no Alt-bound keyboard shortcuts on Macintosh, ever - it is used on international keyboards as the compose key (for a long time, we didn't know it, but Norwegian and French users could not type } or { in NetBeans - kind of limits the usefuless of a Java IDE)." I'm on MacOS now, on a US keyboard, and in fact, most alt+key combinations do produce valid characters (e.g. asdf=????). On non-US keyboards, these combinations might be the only way to produce certain "common" characters (e.g. {}, as the NetBeans page mentions). I'm not familiar with JDK internals, so my apologies if the observations above are not relevant here. -- Eirik On 12/10/14, 12:56 PM, "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? > >-- >Best regards, >Sergey A. Malenkov >JetBrains From malenkov at gmail.com Wed Dec 10 19:06:41 2014 From: malenkov at gmail.com (Sergey Malenkov) Date: Wed, 10 Dec 2014 22:06:41 +0300 Subject: The input method handling In-Reply-To: References: Message-ID: Thank you for the link, but my changes do not remove ability of typing some characters. This is about internal representation of key events. I suggest to do not replace key-typed events with the corresponding input method events for simple inserting of a single character. For example, with Oracle JDK Alt-L on German layout generates key-typed event for '@', but Alt-K generates input event for '?'. Why? The only difference is that '@' contains 1 byte in UTF8. But Java characters consist of 2 bytes each, so we should not generate simple input method events if we can use key-typed events. Note that Alt-E on English layout generates *complex* input method event, but my fix does not affect such cases. -- Best regards, Sergey A. Malenkov On Wed, Dec 10, 2014 at 9:26 PM, Eirik Bakke wrote: > Passing by--maybe the following piece of NetBeans Platform documentation > has relevance: > > http://wiki.netbeans.org/DevFaqLogicalKeybindings > > > Quote: "There should be no Alt-bound keyboard shortcuts on Macintosh, ever > - it is used on international keyboards as the compose key (for a long > time, we didn't know it, but Norwegian and French users could not type } > or { in NetBeans - kind of limits the usefuless of a Java IDE)." > > > I'm on MacOS now, on a US keyboard, and in fact, most alt+key combinations > do produce valid characters (e.g. asdf=?? ?). On non-US keyboards, these > combinations might be the only way to produce certain "common" characters > (e.g. {}, as the NetBeans page mentions). > > I'm not familiar with JDK internals, so my apologies if the observations > above are not relevant here. > > -- Eirik > > On 12/10/14, 12:56 PM, "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? >> >>-- >>Best regards, >>Sergey A. Malenkov >>JetBrains From naoto.sato at oracle.com Wed Dec 10 19:21:02 2014 From: naoto.sato at oracle.com (Naoto Sato) Date: Wed, 10 Dec 2014 11:21:02 -0800 Subject: The input method handling In-Reply-To: References: Message-ID: <54889D1E.7030204@oracle.com> 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? > From ebakke at mit.edu Wed Dec 10 22:25:00 2014 From: ebakke at mit.edu (Eirik Bakke) Date: Wed, 10 Dec 2014 22:25:00 +0000 Subject: The input method handling In-Reply-To: References:

Message-ID: Ah, makes sense. Thanks for the explanation. -- Eirik On 12/10/14, 2:06 PM, "Sergey Malenkov" wrote: >Thank you for the link, but my changes do not remove ability of typing >some characters. This is about internal representation of key events. >I suggest to do not replace key-typed events with the corresponding >input method events for simple inserting of a single character. > >For example, with Oracle JDK Alt-L on German layout generates >key-typed event for '@', but Alt-K generates input event for '?'. Why? >The only difference is that '@' contains 1 byte in UTF8. But Java >characters consist of 2 bytes each, so we should not generate simple >input method events if we can use key-typed events. > >Note that Alt-E on English layout generates *complex* input method >event, but my fix does not affect such cases. > >-- >Best regards, >Sergey A. Malenkov > > >On Wed, Dec 10, 2014 at 9:26 PM, Eirik Bakke wrote: >> Passing by--maybe the following piece of NetBeans Platform documentation >> has relevance: >> >> http://wiki.netbeans.org/DevFaqLogicalKeybindings >> >> >> Quote: "There should be no Alt-bound keyboard shortcuts on Macintosh, >>ever >> - it is used on international keyboards as the compose key (for a long >> time, we didn't know it, but Norwegian and French users could not type } >> or { in NetBeans - kind of limits the usefuless of a Java IDE)." >> >> >> I'm on MacOS now, on a US keyboard, and in fact, most alt+key >>combinations >> do produce valid characters (e.g. asdf=?? ?). On non-US keyboards, these >> combinations might be the only way to produce certain "common" >>characters >> (e.g. {}, as the NetBeans page mentions). >> >> I'm not familiar with JDK internals, so my apologies if the observations >> above are not relevant here. >> >> -- Eirik >> >> On 12/10/14, 12:56 PM, "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.deskt >>>op >>>/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? >>> >>>-- >>>Best regards, >>>Sergey A. Malenkov >>>JetBrains From malenkov at gmail.com Thu Dec 11 11:15:03 2014 From: malenkov at gmail.com (Sergey Malenkov) Date: Thu, 11 Dec 2014 14:15:03 +0300 Subject: The input method handling In-Reply-To: <54889D1E.7030204@oracle.com> References: <54889D1E.7030204@oracle.com> Message-ID: 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 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? >> > -- Best regards, Sergey A. Malenkov From naoto.sato at oracle.com Thu Dec 11 21:04:07 2014 From: naoto.sato at oracle.com (Naoto Sato) Date: Thu, 11 Dec 2014 13:04:07 -0800 Subject: The input method handling In-Reply-To: References: <54889D1E.7030204@oracle.com> Message-ID: <548A06C7.3040907@oracle.com> 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 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? >>> >> > > > From malenkov at gmail.com Fri Dec 12 11:07:52 2014 From: malenkov at gmail.com (Sergey Malenkov) Date: Fri, 12 Dec 2014 14:07:52 +0300 Subject: The input method handling In-Reply-To: <548A06C7.3040907@oracle.com> References: <54889D1E.7030204@oracle.com> <548A06C7.3040907@oracle.com> Message-ID: 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 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 >> 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? >>>> >>> >> >> >> > -- Best regards, Sergey A. Malenkov From naoto.sato at oracle.com Fri Dec 12 18:11:46 2014 From: naoto.sato at oracle.com (Naoto Sato) Date: Fri, 12 Dec 2014 10:11:46 -0800 Subject: The input method handling In-Reply-To: References: <54889D1E.7030204@oracle.com> <548A06C7.3040907@oracle.com> Message-ID: <548B2FE2.6040904@oracle.com> 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 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 >>> 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? >>>>> >>>> >>> >>> >>> >> > > > From aleksej.efimov at oracle.com Mon Dec 15 16:06:57 2014 From: aleksej.efimov at oracle.com (Aleksej Efimov) Date: Mon, 15 Dec 2014 19:06:57 +0300 Subject: RFR: 8051641: Africa/Casablanca transitions is incorrectly calculated starting from 2027 Message-ID: <548F0721.7080500@oracle.com> Hello Sherman, Masayoshi and other experts, Can I ask for a JDK9 review for the sun/util/calendar/zi/TestZoneInfo310.java test failure [1] that was caused by incorrect handling of last rules for Africa/Casablanca time zone. This timzone has two last rules and three instant rules in a range of these last rules that causes incorrect instant transitions table generation. The proposed fix [2] solves this problem. Also there is a modification to test class that solves the issue with not optimized instant transitions with the same offset/saving values that are the last two in instant transitions table. And TestZoneInfo310.java is removed from problems list. Testing: All tz related test were executed with no failures. JPRT build/testing successfull for all platforms. Best Regards, Aleksej [1] https://bugs.openjdk.java.net/browse/JDK-8051641 [2] http://cr.openjdk.java.net/~aefimov/8051641/9/webrev.00/ From xueming.shen at oracle.com Mon Dec 15 16:17:08 2014 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 15 Dec 2014 08:17:08 -0800 Subject: RFR: 8051641: Africa/Casablanca transitions is incorrectly calculated starting from 2027 In-Reply-To: <548F0721.7080500@oracle.com> References: <548F0721.7080500@oracle.com> Message-ID: <548F0984.9000507@oracle.com> On 12/15/14 8:06 AM, Aleksej Efimov wrote: > Hello Sherman, Masayoshi and other experts, > > Can I ask for a JDK9 review for the > sun/util/calendar/zi/TestZoneInfo310.java test failure [1] that was > caused by incorrect handling of last rules for Africa/Casablanca time > zone. This timzone has two last rules and three instant rules in a > range of these last rules that causes incorrect instant transitions > table generation. The proposed fix [2] solves this problem. Also there > is a modification to test class that solves the issue with not > optimized instant transitions with the same offset/saving values that > are the last two in instant transitions table. And > TestZoneInfo310.java is removed from problems list. > > Testing: > All tz related test were executed with no failures. > JPRT build/testing successfull for all platforms. > > Best Regards, > Aleksej > > [1] https://bugs.openjdk.java.net/browse/JDK-8051641 > [2] http://cr.openjdk.java.net/~aefimov/8051641/9/webrev.00/ > Hi Aleksej, The fix itself is good. The lines in Rules.java need adjust the space and blank line at #736 at provider.java need to be removed as well (my fault). Thanks! -Sherman From aleksej.efimov at oracle.com Mon Dec 15 16:22:44 2014 From: aleksej.efimov at oracle.com (Aleksej Efimov) Date: Mon, 15 Dec 2014 19:22:44 +0300 Subject: RFR: 8051641: Africa/Casablanca transitions is incorrectly calculated starting from 2027 In-Reply-To: <548F0984.9000507@oracle.com> References: <548F0721.7080500@oracle.com> <548F0984.9000507@oracle.com> Message-ID: <548F0AD4.6000100@oracle.com> Sherman, thank you for looking into this problem and helping solve it. I will change the formatting before the push. -Aleksej On 12/15/2014 07:17 PM, Xueming Shen wrote: > On 12/15/14 8:06 AM, Aleksej Efimov wrote: >> Hello Sherman, Masayoshi and other experts, >> >> Can I ask for a JDK9 review for the >> sun/util/calendar/zi/TestZoneInfo310.java test failure [1] that was >> caused by incorrect handling of last rules for Africa/Casablanca time >> zone. This timzone has two last rules and three instant rules in a >> range of these last rules that causes incorrect instant transitions >> table generation. The proposed fix [2] solves this problem. Also >> there is a modification to test class that solves the issue with not >> optimized instant transitions with the same offset/saving values that >> are the last two in instant transitions table. And >> TestZoneInfo310.java is removed from problems list. >> >> Testing: >> All tz related test were executed with no failures. >> JPRT build/testing successfull for all platforms. >> >> Best Regards, >> Aleksej >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8051641 >> [2] http://cr.openjdk.java.net/~aefimov/8051641/9/webrev.00/ >> > Hi Aleksej, > > The fix itself is good. The lines in Rules.java need adjust the space > and blank > line at #736 at provider.java need to be removed as well (my fault). > > Thanks! > -Sherman From naoto.sato at oracle.com Mon Dec 15 22:15:22 2014 From: naoto.sato at oracle.com (Naoto Sato) Date: Mon, 15 Dec 2014 14:15:22 -0800 Subject: [9]RFR: 8062588: Support java.util.spi.*, java.text.spi.*, java.awt.im.spi loaded from classpath Message-ID: <548F5D7A.5000609@oracle.com> Hello, Please review the proposed changes for the following issue: https://bugs.openjdk.java.net/browse/JDK-8062588 The proposed fix is located at: http://cr.openjdk.java.net/~naoto/8062588/webrev.00/ The change is to load SPI implementations from application's class path instead of the extension mechanism, which is removed with the JEP 220. Naoto From Alan.Bateman at oracle.com Tue Dec 16 15:54:30 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 16 Dec 2014 15:54:30 +0000 Subject: [9]RFR: 8062588: Support java.util.spi.*, java.text.spi.*, java.awt.im.spi loaded from classpath In-Reply-To: <548F5D7A.5000609@oracle.com> References: <548F5D7A.5000609@oracle.com> Message-ID: <549055B6.3020702@oracle.com> On 15/12/2014 22:15, Naoto Sato wrote: > Hello, > > Please review the proposed changes for the following issue: > > https://bugs.openjdk.java.net/browse/JDK-8062588 > > The proposed fix is located at: > > http://cr.openjdk.java.net/~naoto/8062588/webrev.00/ > > The change is to load SPI implementations from application's class > path instead of the extension mechanism, which is removed with the JEP > 220. ServiceLoader.load uses the TCCL. I suspect you are looking for ServiceLoader.load(c, ClassLoader.getSystemClassLoader()). -Alan. From naoto.sato at oracle.com Tue Dec 16 17:59:26 2014 From: naoto.sato at oracle.com (Naoto Sato) Date: Tue, 16 Dec 2014 09:59:26 -0800 Subject: [9]RFR: 8062588: Support java.util.spi.*, java.text.spi.*, java.awt.im.spi loaded from classpath In-Reply-To: <549055B6.3020702@oracle.com> References: <548F5D7A.5000609@oracle.com> <549055B6.3020702@oracle.com> Message-ID: <549072FE.3080700@oracle.com> Hi Alan, Thanks for the review. Modified the fix as you suggested: http://cr.openjdk.java.net/~naoto/8062588/webrev.01/ Naoto On 12/16/14 7:54 AM, Alan Bateman wrote: > On 15/12/2014 22:15, Naoto Sato wrote: >> Hello, >> >> Please review the proposed changes for the following issue: >> >> https://bugs.openjdk.java.net/browse/JDK-8062588 >> >> The proposed fix is located at: >> >> http://cr.openjdk.java.net/~naoto/8062588/webrev.00/ >> >> The change is to load SPI implementations from application's class >> path instead of the extension mechanism, which is removed with the JEP >> 220. > ServiceLoader.load uses the TCCL. I suspect you are looking for > ServiceLoader.load(c, ClassLoader.getSystemClassLoader()). > > -Alan. From Alan.Bateman at oracle.com Tue Dec 16 20:33:29 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 16 Dec 2014 20:33:29 +0000 Subject: [9]RFR: 8062588: Support java.util.spi.*, java.text.spi.*, java.awt.im.spi loaded from classpath In-Reply-To: <549072FE.3080700@oracle.com> References: <548F5D7A.5000609@oracle.com> <549055B6.3020702@oracle.com> <549072FE.3080700@oracle.com> Message-ID: <54909719.5010208@oracle.com> On 16/12/2014 17:59, Naoto Sato wrote: > Hi Alan, > > Thanks for the review. Modified the fix as you suggested: > > http://cr.openjdk.java.net/~naoto/8062588/webrev.01/ This looks okay to me now. -Alan From malenkov at gmail.com Fri Dec 26 11:15:41 2014 From: malenkov at gmail.com (Sergey Malenkov) Date: Fri, 26 Dec 2014 14:15:41 +0300 Subject: The input method handling In-Reply-To: <549C66B2.6030709@oracle.com> References: <549C66B2.6030709@oracle.com> Message-ID: Hi Anton, Could you please look at the following SR from JetBrains: SR #3-10041822951: Java on Mac: Unexpected InputMethodEvent is created https://support.oracle.com/epmos/faces/SrDetail?srNumber=3-10041822951 It contains the patch that is more correct than in the JDK-8068283. Now we are testing it with locally built JDK. Thanks, SAM On Thu, Dec 25, 2014 at 10:34 PM, Anton Nashatyrev wrote: > Hi Sergey, > > here is corresponding JBS issue for your problem: > https://bugs.openjdk.java.net/browse/JDK-8068283 > I've made some initial evaluation there. > > Regards, > Anton. > > > On 10.12.2014 20:56, 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? >> > -- Best regards, Sergey A. Malenkov From aleksej.efimov at oracle.com Sun Dec 28 11:02:59 2014 From: aleksej.efimov at oracle.com (Aleksej Efimov) Date: Sun, 28 Dec 2014 14:02:59 +0300 Subject: [8u-dev] 8051641: Request for Approval: Africa/Casablanca transitions is incorrectly calculated starting from 2027 Message-ID: <549FE363.3030309@oracle.com> Hi, Can I have an approval for the backport of 8051641. The backport slightly differs from JDK9 for ZoneRulesBuilder.java. Adding the original reviewer and alias for review. Testing: All TZ related tests shows PASS result, the JPRT testing shows no failures too. Webrev: http://cr.openjdk.java.net/~aefimov/8051641/8/webrev.00/ JBS bug: https://bugs.openjdk.java.net/browse/JDK-8051641 JDK9 review: http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-December/030348.html JDK9 changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/8bb2d5d056bf With Best Wishes, Aleksej From xueming.shen at oracle.com Mon Dec 29 18:18:42 2014 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 29 Dec 2014 10:18:42 -0800 Subject: [8u-dev] 8051641: Request for Approval: Africa/Casablanca transitions is incorrectly calculated starting from 2027 In-Reply-To: <549FE363.3030309@oracle.com> References: <549FE363.3030309@oracle.com> Message-ID: <54A19B02.8000602@oracle.com> On 12/28/2014 03:02 AM, Aleksej Efimov wrote: > Hi, > > Can I have an approval for the backport of 8051641. The backport slightly differs from JDK9 for ZoneRulesBuilder.java. Adding the original reviewer and alias for review. > Testing: All TZ related tests shows PASS result, the JPRT testing shows no failures too. > > Webrev: http://cr.openjdk.java.net/~aefimov/8051641/8/webrev.00/ > JBS bug: https://bugs.openjdk.java.net/browse/JDK-8051641 > JDK9 review: http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-December/030348.html > JDK9 changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/8bb2d5d056bf > > With Best Wishes, > Aleksej looks fine. -Sherman From anton.nashatyrev at oracle.com Thu Dec 25 19:34:10 2014 From: anton.nashatyrev at oracle.com (Anton Nashatyrev) Date: Thu, 25 Dec 2014 22:34:10 +0300 Subject: The input method handling In-Reply-To: References: Message-ID: <549C66B2.6030709@oracle.com> Hi Sergey, here is corresponding JBS issue for your problem: https://bugs.openjdk.java.net/browse/JDK-8068283 I've made some initial evaluation there. Regards, Anton. On 10.12.2014 20:56, 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? > From rob.mckenna at oracle.com Mon Dec 29 18:08:23 2014 From: rob.mckenna at oracle.com (Rob McKenna) Date: Mon, 29 Dec 2014 18:08:23 +0000 Subject: [8u-dev] 8051641: Request for Approval: Africa/Casablanca transitions is incorrectly calculated starting from 2027 In-Reply-To: <549FE363.3030309@oracle.com> References: <549FE363.3030309@oracle.com> Message-ID: <54A19897.7080906@oracle.com> Approved pending codreview. -Rob On 28/12/14 11:02, Aleksej Efimov wrote: > Hi, > > Can I have an approval for the backport of 8051641. The backport > slightly differs from JDK9 for ZoneRulesBuilder.java. Adding the > original reviewer and alias for review. > Testing: All TZ related tests shows PASS result, the JPRT testing > shows no failures too. > > Webrev: http://cr.openjdk.java.net/~aefimov/8051641/8/webrev.00/ > JBS bug: https://bugs.openjdk.java.net/browse/JDK-8051641 > JDK9 review: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-December/030348.html > JDK9 changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/8bb2d5d056bf > > With Best Wishes, > Aleksej