From takiguc at linux.vnet.ibm.com Mon Feb 4 12:53:44 2019 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Mon, 04 Feb 2019 21:53:44 +0900 Subject: RFR: 8212678 Windows IME related patch In-Reply-To: <65a12ea2c1e684c5ccf236db37c2a9ad@linux.vnet.ibm.com> References:

<75b8dabc3f52417885a0a1f1e3aec719@linux.vnet.ibm.com> <1704b65b98f5521a57fdea529a597671@linux.vnet.ibm.com> <65a12ea2c1e684c5ccf236db37c2a9ad@linux.vnet.ibm.com> Message-ID: <6a6fa4b47925d40cf911c2ed8d4c157d@linux.vnet.ibm.com> Hello. Could you review the fix and give me your suggestion, please ? JDK-8212678 [1] has screen shots and movies. Please check them also. [1] https://bugs.openjdk.java.net/browse/JDK-8212678 Thanks, Ichiroh Takiguchi On 2019-01-23 21:18, Ichiroh Takiguchi wrote: > Hello. > > Could you review the fix and give me your suggestion ? > > Thanks, > Ichiroh Takiguchi > > On 2019-01-16 20:13, Ichiroh Takiguchi wrote: >> Hello. >> >> Could you review the fix ? >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8212678 >> Change: https://cr.openjdk.java.net/~itakiguchi/8212678/webrev.01/ >> >> 3 issues were combined. >> 2 issues are recreatable on English Windows. >> >> Screen shots and movies are attached into JDK-8212678. >> Please check them. >> >> I'd like to obtain a sponsor for this issue. >> >> Thanks, >> Ichiroh Takiguchi >> IBM Japan, Ltd. >> >> On 2018-11-18 22:22, Ichiroh Takiguchi wrote: >>> Hello. >>> >>> Could you review the fix ? >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8212678 >>> Change: http://cr.openjdk.java.net/~aleonard/winime/webrev.00/ >>> >>> Test instruction is in JDK-8212678. >>> This fix may improve CJK IME operation. >>> >>> I'd like to obtain a sponsor for this issue. >>> >>> Thanks, >>> Ichiroh Takiguchi >>> IBM Japan, Ltd. >>> >>> On 2018-06-15 02:26, Phil Race wrote: >>>> This should go to i18n-dev as well. >>>> >>>> -phil. >>>> >>>> On 06/14/2018 10:14 AM, Ichiroh Takiguchi wrote: >>>>> Hello, >>>>> IBM would like to contribute Windows IME related Java Input Method >>>>> Framework patch to OpenJDK project. >>>>> >>>>> Issue: >>>>> This patch can fix following issues. >>>>> A: Cannot display surrogate pair character on Windows floating IME >>>>> window for passive component >>>>> B: Control Windows IME status by using InputSubset and UnicodeBlock >>>>> for CJK countries >>>>> C: Check preedit string availability for Windows Chinese IME >>>>> >>>>> To recreate each issue. >>>>> >>>>> Issue A: >>>>> 1. Run SwingSet2 Java demo program with Japanese IME. >>>>> 2. Click InternalFrameDemo's "Frame 0". >>>>> 3. Turn on Japanese IME, then type "2000B" and press F5 key. >>>>> The character is not displayed properly. [1] >>>>> >>>>> Issue B: >>>>> Test program (ImSubsetsTest.java) is as follow: >>>>> http://cr.openjdk.java.net/~aleonard/winime/ImSubsetsTest.java >>>>> >>>>> 1. Compile and run ImSubsetsTest with CJK IMEs >>>>> 2. Select language (ja:Japanese, ko:Korean, zh: Chinese). >>>>> Windows IME (same langugae's one) should be turned on. >>>>> 3. Click JTextField (active component) or JButton (passive >>>>> component) >>>>> (Please check IM status is changed or not) >>>>> 4. Click different color's JTextField (active component) or JButton >>>>> (passive component) >>>>> (Please check IM status is changed or not) >>>>> 5. Following operations did not work >>>>> Korean IME : HANJA->LATIN_DIGIT,BASIC_LATIN >>>>> Chinese IME : FULLWIDTH_DIGITS->LATIN_DIGIT,BASIC_LATIN >>>>> >>>>> Issue C: >>>>> Test program is as follows: >>>>> ====== >>>>> import javax.swing.*; >>>>> >>>>> public class IMFTestA extends JFrame { >>>>> IMFTestA(int width, int height, int x, int y) { >>>>> super("JTextArea"); >>>>> add(new JTextArea()); >>>>> setSize(width, height); >>>>> setLocation(x, y); >>>>> setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); >>>>> setVisible(true); >>>>> } >>>>> public static void main(String[] args) { >>>>> new IMFTestA(300, 200, 0, 0); >>>>> new IMFTestA(300, 200, 300, 0); >>>>> } >>>>> } >>>>> ====== >>>>> >>>>> On Chinese IME (Microsoft Pinyin ABC), >>>>> 1. Compile and run IMFTestA >>>>> 2. Click one of JTextArea window, turn ON Chinese IME >>>>> 3. Click the other window, turn ON Chinese IME >>>>> 4. Type "nihao", then preedit string is displayed >>>>> 5. Click the other window, turn OFF Chinese IME >>>>> 6. Click the other window, preedit string is still displayed but >>>>> it's not convertable >>>>> >>>>> Reason: >>>>> Issue A, proper font is not specified for passive component >>>>> Issue B, IME mode setting for CJK Windows IME is not correct >>>>> Issue C, Chinese Windows IME shares IME status between windows, >>>>> Java needs to check preedit string is available or not >>>>> >>>>> I'd like contribute following 3 files: >>>>> M >>>>> src/java.desktop/windows/classes/sun/awt/windows/WInputMethod.java >>>>> M src/java.desktop/windows/native/libawt/windows/awt_Component.cpp >>>>> M >>>>> src/java.desktop/windows/native/libawt/windows/awt_InputMethod.cpp >>>>> http://cr.openjdk.java.net/~aleonard/winime/webrev.00/ >>>>> >>>>> I appreciate any feedback please, and how I would go about >>>>> obtaining a sponsor and contributor? >>>>> >>>>> [1] http://unicode.org/cgi-bin/GetUnihanData.pl?codepoint=2000B >>>>> >>>>> Thanks, >>>>> Ichiroh Takiguchi >>>>> IBM Japan, Ltd. >>>>> From nishit.jain at oracle.com Mon Feb 4 15:31:56 2019 From: nishit.jain at oracle.com (Nishit Jain) Date: Mon, 4 Feb 2019 21:01:56 +0530 Subject: [13] RFR 8217969, 8218265: Base64.Decoder.decode methods ... and java/util/Base64/TestEncodingDecodingLength.java failing Message-ID: Hi, Please review the below fix for 8217969 and 8218265 Bug: https://bugs.openjdk.java.net/browse/JDK-8217969 ???? https://bugs.openjdk.java.net/browse/JDK-8218265 Webrev: http://cr.openjdk.java.net/~nishjain/8217969_8218265/webrev.00/ Issue: Fix for 8210583 changed the Base64.Decoder.decode to throw OOME when an integer value overflows, which is an intermediate value, not the final value, the final value is always less than Integer.MAX_VALUE. Also, the test case written for 8210583, fails on certain platforms and throws "OutOfMemoryError: Requested array size exceeds VM limit ", due to the array size of length Integer.MAX_VALUE - 2. Fix: Handled the integer overflow by storing the intermediate value as "long" and converting the final value as integer. Also, updating the test case input array length to Integer.MAX_VALUE - 8, since MAX_VALUE - 2 was used only to test the overflow condition in Decoder.decode() which is no longer there. Regards, Nishit Jain From Sergey.Bylokhov at oracle.com Thu Feb 14 00:36:42 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 13 Feb 2019 16:36:42 -0800 Subject: RFR: 8212678 Windows IME related patch In-Reply-To: <6a6fa4b47925d40cf911c2ed8d4c157d@linux.vnet.ibm.com> References:

<75b8dabc3f52417885a0a1f1e3aec719@linux.vnet.ibm.com> <1704b65b98f5521a57fdea529a597671@linux.vnet.ibm.com> <65a12ea2c1e684c5ccf236db37c2a9ad@linux.vnet.ibm.com> <6a6fa4b47925d40cf911c2ed8d4c157d@linux.vnet.ibm.com> Message-ID: <51c63117-37cc-f603-ce48-c8e683621082@oracle.com> +1 Naoto On 2/13/19 4:36 PM, Sergey Bylokhov wrote: > Hi, Ichiroh. > > The fix looks fine, it will be good if someone from i18n team will take > a look. > > On 04/02/2019 04:53, Ichiroh Takiguchi wrote: >> Hello. >> >> Could you review the fix and give me your suggestion, please ? >> JDK-8212678 [1] has screen shots and movies. >> Please check them also. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8212678 >> >> Thanks, >> Ichiroh Takiguchi >> >> On 2019-01-23 21:18, Ichiroh Takiguchi wrote: >>> Hello. >>> >>> Could you review the fix and give me your suggestion ? >>> >>> Thanks, >>> Ichiroh Takiguchi >>> >>> On 2019-01-16 20:13, Ichiroh Takiguchi wrote: >>>> Hello. >>>> >>>> Could you review the fix ? >>>> >>>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8212678 >>>> Change: https://cr.openjdk.java.net/~itakiguchi/8212678/webrev.01/ >>>> >>>> 3 issues were combined. >>>> 2 issues are recreatable on English Windows. >>>> >>>> Screen shots and movies are attached into JDK-8212678. >>>> Please check them. >>>> >>>> I'd like to obtain a sponsor for this issue. >>>> >>>> Thanks, >>>> Ichiroh Takiguchi >>>> IBM Japan, Ltd. >>>> >>>> On 2018-11-18 22:22, Ichiroh Takiguchi wrote: >>>>> Hello. >>>>> >>>>> Could you review the fix ? >>>>> >>>>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8212678 >>>>> Change: http://cr.openjdk.java.net/~aleonard/winime/webrev.00/ >>>>> >>>>> Test instruction is in JDK-8212678. >>>>> This fix may improve CJK IME operation. >>>>> >>>>> I'd like to obtain a sponsor for this issue. >>>>> >>>>> Thanks, >>>>> Ichiroh Takiguchi >>>>> IBM Japan, Ltd. >>>>> >>>>> On 2018-06-15 02:26, Phil Race wrote: >>>>>> This should go to i18n-dev as well. >>>>>> >>>>>> -phil. >>>>>> >>>>>> On 06/14/2018 10:14 AM, Ichiroh Takiguchi wrote: >>>>>>> Hello, >>>>>>> IBM would like to contribute Windows IME related Java Input >>>>>>> Method Framework patch to OpenJDK project. >>>>>>> >>>>>>> Issue: >>>>>>> This patch can fix following issues. >>>>>>> A: Cannot display surrogate pair character on Windows floating >>>>>>> IME window for passive component >>>>>>> B: Control Windows IME status by using InputSubset and >>>>>>> UnicodeBlock for CJK countries >>>>>>> C: Check preedit string availability for Windows Chinese IME >>>>>>> >>>>>>> To recreate each issue. >>>>>>> >>>>>>> Issue A: >>>>>>> 1. Run SwingSet2 Java demo program with Japanese IME. >>>>>>> 2. Click InternalFrameDemo's "Frame 0". >>>>>>> 3. Turn on Japanese IME, then type "2000B" and press F5 key. >>>>>>> The character is not displayed properly. [1] >>>>>>> >>>>>>> Issue B: >>>>>>> Test program (ImSubsetsTest.java) is as follow: >>>>>>> http://cr.openjdk.java.net/~aleonard/winime/ImSubsetsTest.java >>>>>>> >>>>>>> 1. Compile and run ImSubsetsTest with CJK IMEs >>>>>>> 2. Select language (ja:Japanese, ko:Korean, zh: Chinese). >>>>>>> Windows IME (same langugae's one) should be turned on. >>>>>>> 3. Click? JTextField (active component) or JButton (passive >>>>>>> component) >>>>>>> (Please check IM status is changed or not) >>>>>>> 4. Click different color's JTextField (active component) or >>>>>>> JButton (passive component) >>>>>>> (Please check IM status is changed or not) >>>>>>> 5. Following operations did not work >>>>>>> Korean IME : HANJA->LATIN_DIGIT,BASIC_LATIN >>>>>>> Chinese IME : FULLWIDTH_DIGITS->LATIN_DIGIT,BASIC_LATIN >>>>>>> >>>>>>> Issue C: >>>>>>> Test program is as follows: >>>>>>> ====== >>>>>>> import javax.swing.*; >>>>>>> >>>>>>> public class IMFTestA extends JFrame { >>>>>>> ? IMFTestA(int width, int height, int x, int y) { >>>>>>> ??? super("JTextArea"); >>>>>>> ??? add(new JTextArea()); >>>>>>> ??? setSize(width, height); >>>>>>> ??? setLocation(x, y); >>>>>>> ??? setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); >>>>>>> ??? setVisible(true); >>>>>>> ? } >>>>>>> ? public static void main(String[] args) { >>>>>>> ??? new IMFTestA(300, 200, 0, 0); >>>>>>> ??? new IMFTestA(300, 200, 300, 0); >>>>>>> ? } >>>>>>> } >>>>>>> ====== >>>>>>> >>>>>>> On Chinese IME (Microsoft Pinyin ABC), >>>>>>> 1. Compile and run IMFTestA >>>>>>> 2. Click one of JTextArea window, turn ON Chinese IME >>>>>>> 3. Click the other window, turn ON Chinese IME >>>>>>> 4. Type "nihao", then preedit string is displayed >>>>>>> 5. Click the other window, turn OFF Chinese IME >>>>>>> 6. Click the other window, preedit string is still displayed but >>>>>>> it's not convertable >>>>>>> >>>>>>> Reason: >>>>>>> Issue A, proper font is not specified for passive component >>>>>>> Issue B, IME mode setting for CJK Windows IME is not correct >>>>>>> Issue C, Chinese Windows IME shares IME status between windows, >>>>>>> Java needs to check preedit string is available or not >>>>>>> >>>>>>> I'd like contribute following 3 files: >>>>>>> M src/java.desktop/windows/classes/sun/awt/windows/WInputMethod.java >>>>>>> M src/java.desktop/windows/native/libawt/windows/awt_Component.cpp >>>>>>> M src/java.desktop/windows/native/libawt/windows/awt_InputMethod.cpp >>>>>>> http://cr.openjdk.java.net/~aleonard/winime/webrev.00/ >>>>>>> >>>>>>> I appreciate any feedback please, and how I would go about >>>>>>> obtaining a sponsor and contributor? >>>>>>> >>>>>>> [1] http://unicode.org/cgi-bin/GetUnihanData.pl?codepoint=2000B >>>>>>> >>>>>>> Thanks, >>>>>>> Ichiroh Takiguchi >>>>>>> IBM Japan, Ltd. >>>>>>> >> > > From naoto.sato at oracle.com Fri Feb 15 22:55:11 2019 From: naoto.sato at oracle.com (Naoto Sato) Date: Fri, 15 Feb 2019 14:55:11 -0800 Subject: [13] RFR: CONFIG level logging statements printed in CLDRCalendarDataProviderImpl.java even when default log Level is INFO Message-ID: <0d69b2da-0586-4178-7678-a4a3b82a7ec2@oracle.com> Hello, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8218960 The proposed changeset is located at: http://cr.openjdk.java.net/~naoto/8218960/webrev.00/ The CONFIG message was generated because CLDRCalendarDataProviderImpl was returning null for locales without region. Use "US" as the default region in such a case. Naoto From nishit.jain at oracle.com Tue Feb 19 14:37:35 2019 From: nishit.jain at oracle.com (Nishit Jain) Date: Tue, 19 Feb 2019 20:07:35 +0530 Subject: [13] RFR: CONFIG level logging statements printed in CLDRCalendarDataProviderImpl.java even when default log Level is INFO In-Reply-To: <0d69b2da-0586-4178-7678-a4a3b82a7ec2@oracle.com> References: <0d69b2da-0586-4178-7678-a4a3b82a7ec2@oracle.com> Message-ID: Hi Naoto, Why is the default region set to "US" if there is no region specified in the locale? is this the default behavior of "first day of week" and "minimal days in first week" when a region is missing or the default behavior is that it returns "1"? Can't we just return "1" instead of setting the region to "US"? Regards, Nishit Jain On 16-02-2019 04:25, Naoto Sato wrote: > Hello, > > Please review the fix to the following issue: > > https://bugs.openjdk.java.net/browse/JDK-8218960 > > The proposed changeset is located at: > > http://cr.openjdk.java.net/~naoto/8218960/webrev.00/ > > The CONFIG message was generated because CLDRCalendarDataProviderImpl > was returning null for locales without region. Use "US" as the default > region in such a case. > > Naoto From naoto.sato at oracle.com Tue Feb 19 17:21:00 2019 From: naoto.sato at oracle.com (Naoto Sato) Date: Tue, 19 Feb 2019 09:21:00 -0800 Subject: [13] RFR: CONFIG level logging statements printed in CLDRCalendarDataProviderImpl.java even when default log Level is INFO In-Reply-To: References: <0d69b2da-0586-4178-7678-a4a3b82a7ec2@oracle.com> Message-ID: <82b5aa63-75e6-3a01-7f53-fd4dc389676d@oracle.com> Hi Nishit, The reason is that "US" is the only required locale in the JDK (cf. Locale.getAvailableLocales(). In fact, initially I supplied "001" with it, as it means the "world" in CLDR, but it broke some existing tests. "001" returns "MONDAY" as the first day of week, whereas "SUNDAY" in US. For the compatibility reason, I had to resort to "US". I am not sure we want to hardcode "1" in this case without any convincing reason. Naoto On 2/19/19 6:37 AM, Nishit Jain wrote: > Hi Naoto, > > Why is the default region set to "US" if there is no region specified in > the locale? is this the default behavior of "first day of week" and > "minimal days in first week" when a region is missing or the default > behavior is that it returns "1"? Can't we just return "1" instead of > setting the region to "US"? > > Regards, > Nishit Jain > On 16-02-2019 04:25, Naoto Sato wrote: >> Hello, >> >> Please review the fix to the following issue: >> >> https://bugs.openjdk.java.net/browse/JDK-8218960 >> >> The proposed changeset is located at: >> >> http://cr.openjdk.java.net/~naoto/8218960/webrev.00/ >> >> The CONFIG message was generated because CLDRCalendarDataProviderImpl >> was returning null for locales without region. Use "US" as the default >> region in such a case. >> >> Naoto > From nishit.jain at oracle.com Wed Feb 20 08:33:14 2019 From: nishit.jain at oracle.com (Nishit Jain) Date: Wed, 20 Feb 2019 14:03:14 +0530 Subject: [13] RFR: CONFIG level logging statements printed in CLDRCalendarDataProviderImpl.java even when default log Level is INFO In-Reply-To: <82b5aa63-75e6-3a01-7f53-fd4dc389676d@oracle.com> References: <0d69b2da-0586-4178-7678-a4a3b82a7ec2@oracle.com> <82b5aa63-75e6-3a01-7f53-fd4dc389676d@oracle.com> Message-ID: Hi Naoto, Thanks for the explanation. Change looks fine to me. Regards, Nishit Jain On 19-02-2019 22:51, Naoto Sato wrote: > Hi Nishit, > > The reason is that "US" is the only required locale in the JDK (cf. > Locale.getAvailableLocales(). In fact, initially I supplied "001" with > it, as it means the "world" in CLDR, but it broke some existing tests. > "001" returns "MONDAY" as the first day of week, whereas "SUNDAY" in > US. For the compatibility reason, I had to resort to "US". I am not > sure we want to hardcode "1" in this case without any convincing reason. > > Naoto > > On 2/19/19 6:37 AM, Nishit Jain wrote: >> Hi Naoto, >> >> Why is the default region set to "US" if there is no region specified >> in the locale? is this the default behavior of "first day of week" >> and "minimal days in first week" when a region is missing or the >> default behavior is that it returns "1"? Can't we just return "1" >> instead of setting the region to "US"? >> >> Regards, >> Nishit Jain >> On 16-02-2019 04:25, Naoto Sato wrote: >>> Hello, >>> >>> Please review the fix to the following issue: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8218960 >>> >>> The proposed changeset is located at: >>> >>> http://cr.openjdk.java.net/~naoto/8218960/webrev.00/ >>> >>> The CONFIG message was generated because >>> CLDRCalendarDataProviderImpl was returning null for locales without >>> region. Use "US" as the default region in such a case. >>> >>> Naoto >> From naoto.sato at oracle.com Wed Feb 20 22:54:58 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Wed, 20 Feb 2019 14:54:58 -0800 Subject: [13] RFR: CONFIG level logging statements printed in CLDRCalendarDataProviderImpl.java even when default log Level is INFO In-Reply-To: References: <0d69b2da-0586-4178-7678-a4a3b82a7ec2@oracle.com> <82b5aa63-75e6-3a01-7f53-fd4dc389676d@oracle.com> Message-ID: <5c858614-ea1f-cc7a-e98b-3ac8c3379db1@oracle.com> Thanks, Nishit. I'd still like to ask for a review from a Reviewer. Naoto On 2/20/19 12:33 AM, Nishit Jain wrote: > Hi Naoto, > > Thanks for the explanation. Change looks fine to me. > > Regards, > Nishit Jain > On 19-02-2019 22:51, Naoto Sato wrote: >> Hi Nishit, >> >> The reason is that "US" is the only required locale in the JDK (cf. >> Locale.getAvailableLocales(). In fact, initially I supplied "001" with >> it, as it means the "world" in CLDR, but it broke some existing tests. >> "001" returns "MONDAY" as the first day of week, whereas "SUNDAY" in >> US. For the compatibility reason, I had to resort to "US". I am not >> sure we want to hardcode "1" in this case without any convincing reason. >> >> Naoto >> >> On 2/19/19 6:37 AM, Nishit Jain wrote: >>> Hi Naoto, >>> >>> Why is the default region set to "US" if there is no region specified >>> in the locale? is this the default behavior of "first day of week" >>> and "minimal days in first week" when a region is missing or the >>> default behavior is that it returns "1"? Can't we just return "1" >>> instead of setting the region to "US"? >>> >>> Regards, >>> Nishit Jain >>> On 16-02-2019 04:25, Naoto Sato wrote: >>>> Hello, >>>> >>>> Please review the fix to the following issue: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8218960 >>>> >>>> The proposed changeset is located at: >>>> >>>> http://cr.openjdk.java.net/~naoto/8218960/webrev.00/ >>>> >>>> The CONFIG message was generated because >>>> CLDRCalendarDataProviderImpl was returning null for locales without >>>> region. Use "US" as the default region in such a case. >>>> >>>> Naoto >>> > From nishit.jain at oracle.com Fri Feb 22 13:18:23 2019 From: nishit.jain at oracle.com (Nishit Jain) Date: Fri, 22 Feb 2019 18:48:23 +0530 Subject: [13] RFR 8209175: Handle 'B' character introduced in CLDR 33 JDK update for Burmese (my) locale Message-ID: <48a1b8bd-7053-5dc8-782a-58fd174b4280@oracle.com> Hi, Please review the fix for JDK-8209175 Bug: https://bugs.openjdk.java.net/browse/JDK-8209175 Webrev: http://cr.openjdk.java.net/~nishjain/8209175/webrev.03/ Issue: In CLDR 33 update, 'B' character has been added in date time patterns for Burmese locale, which is used to represent the day period. This character is not supported in DateTimeFormatter or SimpleDateFormat APIs, so an exception is thrown that an "unknown character is encountered" Fix: A workaround is added in which 'B' character appearing in CLDR date-time pattern is replaced with 'a' character and hence resolved with am/pm strings. This is based on the LDML specification given for 'B' character in which it falls back to 'a' character if it is not supported by any locale. Regards, Nishit Jain From naoto.sato at oracle.com Fri Feb 22 18:53:15 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Fri, 22 Feb 2019 10:53:15 -0800 Subject: [13] RFR 8209175: Handle 'B' character introduced in CLDR 33 JDK update for Burmese (my) locale In-Reply-To: <48a1b8bd-7053-5dc8-782a-58fd174b4280@oracle.com> References: <48a1b8bd-7053-5dc8-782a-58fd174b4280@oracle.com> Message-ID: <5fba7e87-8e73-2c9a-d831-94a0be9df3eb@oracle.com> Hi Nishit, Looks good to me. One minor typo: Bundle.java:line 699 "SimpledateFormat" -> "SimpleDateFormat". No further review is needed for this. Naoto On 2/22/19 5:18 AM, Nishit Jain wrote: > Hi, > > Please review the fix for JDK-8209175 > > Bug: https://bugs.openjdk.java.net/browse/JDK-8209175 > Webrev: http://cr.openjdk.java.net/~nishjain/8209175/webrev.03/ > > > Issue: In CLDR 33 update, 'B' character has been added in date time > patterns for Burmese locale, which is used to represent the day period. > This character is not supported in DateTimeFormatter or SimpleDateFormat > APIs, so an exception is thrown that an "unknown character is encountered" > > Fix: A workaround is added in which 'B' character appearing in CLDR > date-time pattern is replaced with 'a' character and hence resolved with > am/pm strings. This is based on the LDML specification given for 'B' > character in which it falls back to 'a' character if it is not supported > by any locale. > > > Regards, > Nishit Jain From takiguc at linux.vnet.ibm.com Tue Feb 26 13:08:09 2019 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Tue, 26 Feb 2019 22:08:09 +0900 Subject: RFR: 8213232 Unix/X11 setCompositionEnableNative issue In-Reply-To: <0a651f1099a96e314573b6b8c9f60e6c@linux.vnet.ibm.com> References: <9ad6f2166ea8eabcf7391feccf9d8915@linux.vnet.ibm.com> <0a651f1099a96e314573b6b8c9f60e6c@linux.vnet.ibm.com> Message-ID: <50e98ca5cbdc56a5a13b0754968521c2@linux.vnet.ibm.com> Hello. Could you review the fix ? Bug: https://bugs.openjdk.java.net/browse/JDK-8213232 Change: https://cr.openjdk.java.net/~itakiguchi/8213232/webrev.01/ JDK-8213232 [1] has movies. Please check it. I applied following changes on webrev.01: 1. According to "Xlib - C Language X Interface" [2] See "Preedit State Callbacks" section: PreeditStartCallback() should return int. 2. Add 64bit Big Endian CPU support, like s390x 3. Change copyright year [1] https://bugs.openjdk.java.net/browse/JDK-8213232 [2] https://www.x.org/releases/X11R7.6/doc/libX11/specs/libX11/libX11.html Thanks, Ichiroh Takiguchi IBM Japan, Ltd. On 2018-12-04 11:22, Ichiroh Takiguchi wrote: > Hello. > > Could you review the fix ? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8213232 > Change: https://cr.openjdk.java.net/~itakiguchi/8213232/webrev.00/ > > This issue is related by wrong usage of XNPreeditState on > XSetICValues(). > Because of wrong usage, UnsupportedOperationException exception > happened with Xlib bundled input method. > Test instructions is in JDK-8213232. > > I'd like to obtain a sponsor for this issue. > > Thanks, > Ichiroh Takiguchi > IBM Japan, Ltd. > > On 2018-06-19 02:15, Ichiroh Takiguchi wrote: >> Hello, >> IBM would like to contribute Unix/X11 setCompositionEnableNative issue >> patch to OpenJDK project. >> >> Issue: >> To turn on or turn off IME via Java, XNPreeditState should be used >> with XSetValues(). >> But it should be nested via XVaCreateNestedList() since XNPreeditState >> is a part of XNPreeditAttributes. >> Current code is, like: >> - ret = XSetICValues(pX11IMData->current_ic, XNPreeditState, >> - (enable ? XIMPreeditEnable : >> XIMPreeditDisable), NULL); >> But it should be, like: >> + pr_atrb = XVaCreateNestedList(0, >> + XNPreeditState, (enable ? XIMPreeditEnable : >> XIMPreeditDisable), >> + NULL); >> + ret = XSetICValues(pX11IMData->current_ic, XNPreeditAttributes, >> pr_atrb, NULL); >> >> On Linux platform, the issue can check with following test program and >> kinput2 XIM server and >> Wnn8 for Linux/BSD (htt). >> ================== >> import java.awt.*; >> import java.awt.event.*; >> import javax.swing.*; >> >> public class CompositionEnabledTest extends JFrame { >> CompositionEnabledTest() { >> Container c = getContentPane(); >> c.setLayout(new GridLayout(0,2)); >> JButton btn; >> JTextField tf; >> btn = new JButton("Undefined"); >> c.add(btn); >> tf = new JTextField("Undefined"); >> c.add(tf); >> btn = new JButton("Disabled"); >> btn.addFocusListener(new MyFocusListener(false)); >> c.add(btn); >> tf = new JTextField("Disabled"); >> tf.addFocusListener(new MyFocusListener(false)); >> c.add(tf); >> btn = new JButton("Enabled"); >> btn.addFocusListener(new MyFocusListener(true)); >> c.add(btn); >> tf = new JTextField("Enabled"); >> tf.addFocusListener(new MyFocusListener(true)); >> c.add(tf); >> setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); >> pack(); >> setVisible(true); >> } >> class MyFocusListener implements FocusListener { >> boolean state; >> MyFocusListener(boolean state) { >> this.state = state; >> } >> public void focusGained(FocusEvent fe) { >> >> fe.getComponent().getInputContext().setCompositionEnabled(state); >> } >> public void focusLost(FocusEvent fe) { } >> } >> public static void main(String[] args) { >> new CompositionEnabledTest(); >> } >> } >> ================== >> >> Click JTextField and JButton, then XIM server status may be changed. >> If XIM server does not support XNPreeditState, it does not work. >> >> I'd like contribute following 3 files: >> M src/java.desktop/share/classes/sun/awt/im/InputContext.java >> M src/java.desktop/unix/classes/sun/awt/X11InputMethod.java >> M src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c >> >> http://cr.openjdk.java.net/~aleonard/set_composition_enabled/webrev.00/ >> >> I appreciate any feedback please, and how I would go about obtaining a >> sponsor and contributor? >> >> Thanks, >> Ichiroh Takiguchi >> IBM Japan, Ltd. From naoto.sato at oracle.com Thu Feb 28 21:15:07 2019 From: naoto.sato at oracle.com (Naoto Sato) Date: Thu, 28 Feb 2019 13:15:07 -0800 Subject: [13] RFR: 8219890: Calendar.getDisplayName() returns empty string for new Japanese Era on some locales Message-ID: <53771d80-ac68-5a85-846b-3599f45fdb08@oracle.com> Hello, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8219890 The proposed changeset is located at: http://cr.openjdk.java.net/~naoto/8219890/webrev.00/ After the fix for 8217609, some locales return empty string for the display name for the new era. Providing the fallback name from Era instance in such a case. Naoto From lance.andersen at oracle.com Thu Feb 28 21:27:38 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 28 Feb 2019 16:27:38 -0500 Subject: [13] RFR: 8219890: Calendar.getDisplayName() returns empty string for new Japanese Era on some locales In-Reply-To: <53771d80-ac68-5a85-846b-3599f45fdb08@oracle.com> References: <53771d80-ac68-5a85-846b-3599f45fdb08@oracle.com> Message-ID: <90C2C2AD-388C-45C0-9391-6FFF05BC9E54@oracle.com> looks fine Naoto > On Feb 28, 2019, at 4:15 PM, Naoto Sato wrote: > > Hello, > > Please review the fix to the following issue: > > https://bugs.openjdk.java.net/browse/JDK-8219890 > > The proposed changeset is located at: > > http://cr.openjdk.java.net/~naoto/8219890/webrev.00/ > > After the fix for 8217609, some locales return empty string for the display name for the new era. Providing the fallback name from Era instance in such a case. > > Naoto Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com