From naoto.sato at oracle.com  Fri Jun  1 16:11:39 2018
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Fri, 1 Jun 2018 09:11:39 -0700
Subject: <i18n dev> JDK-8201429 - Support AIX Input Method Editor (IME)
 for AWT Input Method Framework (IMF)
In-Reply-To: <363f390f-4fec-8400-ddf7-cb8058101dd6@oracle.com>
References: <e092f07395544dba931102a3e0bf507d@sap.com>
 <88053947-97d2-58f8-2d5c-a980a0e11448@oracle.com>
 <363f390f-4fec-8400-ddf7-cb8058101dd6@oracle.com>
Message-ID: <6d1ccc44-d87e-f82d-fd47-7ffe6e6879ce@oracle.com>

The issue in the current naming scheme (sharing the same class name for 
impls) is that it assumes one X11 im impl per *platform*. Same 
IMs/WindowManagers can be shared across platforms, or one platform can 
have multiple IM/WM (e.g., the example I wrote below MAWT/XAWT 
co-exist), and the current design cannot deal with these situations.

Naoto

On 5/30/18 2:33 PM, Phil Race wrote:
> It is in a platform dependent directory .. and I gather this allows the 
> build to pick up the right one
> without any work here.
> 
> -phil
> 
> On 5/30/2018 2:08 PM, Naoto Sato wrote:
>> Hi,
>>
>> I see that the change introduced the base abstraction class, 
>> X11InputMethodBase. Back in the days I worked on it, X11InputMethod is 
>> the base abstract class, and platform impls. have names representing 
>> them, i.e, MInputMethod for Motif, and XInputMethod for XAWT. Now 
>> X11InputMethod is a platform dependent implementation. It'd be a bit 
>> clearer to use the different impl class names.
>>
>> Naoto
>>
>> On 5/30/18 1:27 PM, Langer, Christoph wrote:
>>> Hi,
>>>
>>> I was just asked to include i18-n dev in the review of the change for 
>>> this Item.
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201429
>>>
>>> Last webrev: http://cr.openjdk.java.net/~clanger/webrevs/8201429.3/
>>>
>>> Unfortunately this request came a bit too late and the change has 
>>> already been pushed: 
>>> http://hg.openjdk.java.net/jdk/client/rev/668463f93ec0
>>>
>>> So this is now merely a notification. However, maybe you can still 
>>> have an eye on this or even do some specific testing. In case you see 
>>> some issue with it, we shall open a follow-up item.
>>>
>>> Thanks
>>> Christoph
>>>
> 

From li.jiang at oracle.com  Mon Jun  4 14:41:59 2018
From: li.jiang at oracle.com (li.jiang at oracle.com)
Date: Mon, 4 Jun 2018 22:41:59 +0800
Subject: <i18n dev> [11] RFR: 8202026 8193552 8204269 : ISO 4217
 Amendment #165 # 166 #167 Update
In-Reply-To: <2099b4c0-b97a-4c1a-f291-fec8f7beb294@oracle.com>
References: <5d50ddec-884c-e78c-4c2c-b9e11d8c3236@oracle.com>
 <62217aa4-16c5-2ec2-15f7-177d0906c53b@oracle.com>
 <2099b4c0-b97a-4c1a-f291-fec8f7beb294@oracle.com>
Message-ID: <9181f81a-00f4-475c-553f-fa155439fa15@oracle.com>

Hi Naoto,

Pls review the updated code:

http://cr.openjdk.java.net/~ljiang/8202026/webrev.02/

- As suggested, clean up the old transition dates.
- Update copyright year.
- ISO 4217 Amendment #167 was published today, which discards the #166, 
so withdraw the change for #166 in webrev.02.

Bug for #167:
https://bugs.openjdk.java.net/browse/JDK-8204269

Test passed on mach5.

Thanks,
Leo

On 26/04/2018 1:00 AM, naoto.sato at oracle.com wrote:
> Hi Leo,
> 
> Although JDK11 is slated in 09/2018, enabling amendment 166 now is 
> technically a bug, as it will be effective from June 4. Please use the 
> transition mechanism in make/data/currency/CurrencyData.properties and 
> test/jdk/java/util/Currency/tablea1.txt.
> 
> OTOH, there are old (past) transition entries. I would clean up those 
> entries, such as:
> 
>  ?326 # LATVIA
>  ?327 LV=LVL;2013-12-31-22-00-00;EUR
> 
> in CurrencyData.properties. This applies to tabela1.txt as well.
> 
> Naoto
> 
> On 4/24/18 8:52 PM, Leo Jiang wrote:
>> Forgot to mention, the tests in Currency fold are passed on Mach5.
>>
>> -Leo
>>
>> On 04/25/2018 09:33 AM, Leo Jiang wrote:
>>> Hi,
>>>
>>> Please review the changes to address the ISO 4217 Amendment 165 166 
>>> update.
>>>
>>> Bug:
>>> https://bugs.openjdk.java.net/browse/JDK-8193552? 165
>>> https://bugs.openjdk.java.net/browse/JDK-8202026? 166
>>>
>>> CR:
>>> http://cr.openjdk.java.net/~ljiang/8202026/webrev.00/
>>>
>>>
>>> Detail:
>>> #165
>>> From:
>>> MAURITANIA??? Ouguiya??? MRO??? 478??? 2
>>> To:
>>> MAURITANIA??? Ouguiya??? MRU??? 929??? 2
>>>
>>> #166
>>> From:
>>> VENEZUELA (BOLIVARIAN REPUBLIC OF)??? Bol?var??? VEF??? 937??? 2
>>> To:
>>> VENEZUELA (BOLIVARIAN REPUBLIC OF)??? Bol?var Soberano??? VES    
>>> 928??? 2
>>>
>>>
>>> Thanks,
>>> Leo

From naoto.sato at oracle.com  Mon Jun  4 18:27:41 2018
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Mon, 4 Jun 2018 11:27:41 -0700
Subject: <i18n dev> [11] RFR: 8202026 8193552 8204269 : ISO 4217
 Amendment #165 # 166 #167 Update
In-Reply-To: <9181f81a-00f4-475c-553f-fa155439fa15@oracle.com>
References: <5d50ddec-884c-e78c-4c2c-b9e11d8c3236@oracle.com>
 <62217aa4-16c5-2ec2-15f7-177d0906c53b@oracle.com>
 <2099b4c0-b97a-4c1a-f291-fec8f7beb294@oracle.com>
 <9181f81a-00f4-475c-553f-fa155439fa15@oracle.com>
Message-ID: <875fa321-9b73-17f4-c63e-b542e32b6424@oracle.com>

Hi Leo,

Change looks good. One leftover from the previous:

 >> in CurrencyData.properties. This applies to tabela1.txt as well.

Can you please clean those LV/LT entries in tablea1.txt as well?

Naoto

On 6/4/18 7:41 AM, li.jiang at oracle.com wrote:
> Hi Naoto,
> 
> Pls review the updated code:
> 
> http://cr.openjdk.java.net/~ljiang/8202026/webrev.02/
> 
> - As suggested, clean up the old transition dates.
> - Update copyright year.
> - ISO 4217 Amendment #167 was published today, which discards the #166, 
> so withdraw the change for #166 in webrev.02.
> 
> Bug for #167:
> https://bugs.openjdk.java.net/browse/JDK-8204269
> 
> Test passed on mach5.
> 
> Thanks,
> Leo
> 
> On 26/04/2018 1:00 AM, naoto.sato at oracle.com wrote:
>> Hi Leo,
>>
>> Although JDK11 is slated in 09/2018, enabling amendment 166 now is 
>> technically a bug, as it will be effective from June 4. Please use the 
>> transition mechanism in make/data/currency/CurrencyData.properties and 
>> test/jdk/java/util/Currency/tablea1.txt.
>>
>> OTOH, there are old (past) transition entries. I would clean up those 
>> entries, such as:
>>
>> ??326 # LATVIA
>> ??327 LV=LVL;2013-12-31-22-00-00;EUR
>>
>> in CurrencyData.properties. This applies to tabela1.txt as well.
>>
>> Naoto
>>
>> On 4/24/18 8:52 PM, Leo Jiang wrote:
>>> Forgot to mention, the tests in Currency fold are passed on Mach5.
>>>
>>> -Leo
>>>
>>> On 04/25/2018 09:33 AM, Leo Jiang wrote:
>>>> Hi,
>>>>
>>>> Please review the changes to address the ISO 4217 Amendment 165 166 
>>>> update.
>>>>
>>>> Bug:
>>>> https://bugs.openjdk.java.net/browse/JDK-8193552? 165
>>>> https://bugs.openjdk.java.net/browse/JDK-8202026? 166
>>>>
>>>> CR:
>>>> http://cr.openjdk.java.net/~ljiang/8202026/webrev.00/
>>>>
>>>>
>>>> Detail:
>>>> #165
>>>> From:
>>>> MAURITANIA??? Ouguiya??? MRO??? 478??? 2
>>>> To:
>>>> MAURITANIA??? Ouguiya??? MRU??? 929??? 2
>>>>
>>>> #166
>>>> From:
>>>> VENEZUELA (BOLIVARIAN REPUBLIC OF)??? Bol?var??? VEF??? 937??? 2
>>>> To:
>>>> VENEZUELA (BOLIVARIAN REPUBLIC OF)??? Bol?var Soberano??? VES 928??? 2
>>>>
>>>>
>>>> Thanks,
>>>> Leo

From nishit.jain at oracle.com  Tue Jun  5 05:13:08 2018
From: nishit.jain at oracle.com (Nishit Jain)
Date: Tue, 5 Jun 2018 10:43:08 +0530
Subject: <i18n dev> RFR JDK-8203872: Upgrading JDK with latest available LSR
 data from IANA
Message-ID: <6aa57b43-c15e-cfee-cb32-922e4eec8489@oracle.com>

Hi,

Please review the fix for JDK-8203872.

Bug: https://bugs.openjdk.java.net/browse/JDK-8203872
Webrev: http://cr.openjdk.java.net/~nishjain/8203872/webrev.01/

Fix: Updated the LSR data to the version 2017-08-15

Regards,
Nishit Jain

From li.jiang at oracle.com  Tue Jun  5 06:30:16 2018
From: li.jiang at oracle.com (li.jiang at oracle.com)
Date: Tue, 5 Jun 2018 14:30:16 +0800
Subject: <i18n dev> [11] RFR: 8202026 8193552 8204269 : ISO 4217
 Amendment #165 # 166 #167 Update
In-Reply-To: <875fa321-9b73-17f4-c63e-b542e32b6424@oracle.com>
References: <5d50ddec-884c-e78c-4c2c-b9e11d8c3236@oracle.com>
 <62217aa4-16c5-2ec2-15f7-177d0906c53b@oracle.com>
 <2099b4c0-b97a-4c1a-f291-fec8f7beb294@oracle.com>
 <9181f81a-00f4-475c-553f-fa155439fa15@oracle.com>
 <875fa321-9b73-17f4-c63e-b542e32b6424@oracle.com>
Message-ID: <156571a8-d7ab-2c51-39ea-3242e33399f0@oracle.com>

Hi Naoto,

I removed the obsoleted currency LTL and LVL from tablea1.txt, added 
them into otherCodes in ValidateISO4217.java.

new webrev as below:
http://cr.openjdk.java.net/~ljiang/8202026/webrev.03/

Thanks,
Leo

On 05/06/2018 2:27 AM, naoto.sato at oracle.com wrote:
> Hi Leo,
> 
> Change looks good. One leftover from the previous:
> 
>  >> in CurrencyData.properties. This applies to tabela1.txt as well.
> 
> Can you please clean those LV/LT entries in tablea1.txt as well?
> 
> Naoto
> 
> On 6/4/18 7:41 AM, li.jiang at oracle.com wrote:
>> Hi Naoto,
>>
>> Pls review the updated code:
>>
>> http://cr.openjdk.java.net/~ljiang/8202026/webrev.02/
>>
>> - As suggested, clean up the old transition dates.
>> - Update copyright year.
>> - ISO 4217 Amendment #167 was published today, which discards the 
>> #166, so withdraw the change for #166 in webrev.02.
>>
>> Bug for #167:
>> https://bugs.openjdk.java.net/browse/JDK-8204269
>>
>> Test passed on mach5.
>>
>> Thanks,
>> Leo
>>
>> On 26/04/2018 1:00 AM, naoto.sato at oracle.com wrote:
>>> Hi Leo,
>>>
>>> Although JDK11 is slated in 09/2018, enabling amendment 166 now is 
>>> technically a bug, as it will be effective from June 4. Please use 
>>> the transition mechanism in 
>>> make/data/currency/CurrencyData.properties and 
>>> test/jdk/java/util/Currency/tablea1.txt.
>>>
>>> OTOH, there are old (past) transition entries. I would clean up those 
>>> entries, such as:
>>>
>>> ??326 # LATVIA
>>> ??327 LV=LVL;2013-12-31-22-00-00;EUR
>>>
>>> in CurrencyData.properties. This applies to tabela1.txt as well.
>>>
>>> Naoto
>>>
>>> On 4/24/18 8:52 PM, Leo Jiang wrote:
>>>> Forgot to mention, the tests in Currency fold are passed on Mach5.
>>>>
>>>> -Leo
>>>>
>>>> On 04/25/2018 09:33 AM, Leo Jiang wrote:
>>>>> Hi,
>>>>>
>>>>> Please review the changes to address the ISO 4217 Amendment 165 166 
>>>>> update.
>>>>>
>>>>> Bug:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8193552? 165
>>>>> https://bugs.openjdk.java.net/browse/JDK-8202026? 166
>>>>>
>>>>> CR:
>>>>> http://cr.openjdk.java.net/~ljiang/8202026/webrev.00/
>>>>>
>>>>>
>>>>> Detail:
>>>>> #165
>>>>> From:
>>>>> MAURITANIA??? Ouguiya??? MRO??? 478??? 2
>>>>> To:
>>>>> MAURITANIA??? Ouguiya??? MRU??? 929??? 2
>>>>>
>>>>> #166
>>>>> From:
>>>>> VENEZUELA (BOLIVARIAN REPUBLIC OF)??? Bol?var??? VEF??? 937??? 2
>>>>> To:
>>>>> VENEZUELA (BOLIVARIAN REPUBLIC OF)??? Bol?var Soberano??? VES 928??? 2
>>>>>
>>>>>
>>>>> Thanks,
>>>>> Leo

From dipak.kumar at oracle.com  Tue Jun  5 06:32:31 2018
From: dipak.kumar at oracle.com (Dipak Kumar)
Date: Mon, 4 Jun 2018 23:32:31 -0700 (PDT)
Subject: <i18n dev> [11] Review Request: 8202696 glyphs in textfield only
 shown when thai baht-character is added
Message-ID: <17242fed-e6e7-4238-9856-229799ddce1e@default>

Hi,

Please review below fix :

Bug: https://bugs.openjdk.java.net/browse/JDK-8202696 
Webrev: http://cr.openjdk.java.net/~dkumar/8202696/webrev.00/ 

Characters which are not getting displayed actually belong to Phonetic Extensions (https://en.wikipedia.org/wiki/Phonetic_Extensions ).
These characters are not getting rendered properly because they are in exclusion range mentioned in the windows.fontconfig.properties file.
In the above fix, font exclusion ranges have been adjusted so that these characters do not fall within these ranges

Font related Jtreg tests and Mach5 client tests are fine.

Thanks,
Dipak

From naoto.sato at oracle.com  Tue Jun  5 15:48:22 2018
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 5 Jun 2018 08:48:22 -0700
Subject: <i18n dev> [11] RFR: 8202026 8193552 8204269 : ISO 4217
 Amendment #165 # 166 #167 Update
In-Reply-To: <156571a8-d7ab-2c51-39ea-3242e33399f0@oracle.com>
References: <5d50ddec-884c-e78c-4c2c-b9e11d8c3236@oracle.com>
 <62217aa4-16c5-2ec2-15f7-177d0906c53b@oracle.com>
 <2099b4c0-b97a-4c1a-f291-fec8f7beb294@oracle.com>
 <9181f81a-00f4-475c-553f-fa155439fa15@oracle.com>
 <875fa321-9b73-17f4-c63e-b542e32b6424@oracle.com>
 <156571a8-d7ab-2c51-39ea-3242e33399f0@oracle.com>
Message-ID: <37c4fc7a-a6ac-0dc4-be12-a5f7f764e743@oracle.com>

Looks good.

Naoto

On 6/4/18 11:30 PM, li.jiang at oracle.com wrote:
> Hi Naoto,
> 
> I removed the obsoleted currency LTL and LVL from tablea1.txt, added 
> them into otherCodes in ValidateISO4217.java.
> 
> new webrev as below:
> http://cr.openjdk.java.net/~ljiang/8202026/webrev.03/
> 
> Thanks,
> Leo
> 
> On 05/06/2018 2:27 AM, naoto.sato at oracle.com wrote:
>> Hi Leo,
>>
>> Change looks good. One leftover from the previous:
>>
>> ?>> in CurrencyData.properties. This applies to tabela1.txt as well.
>>
>> Can you please clean those LV/LT entries in tablea1.txt as well?
>>
>> Naoto
>>
>> On 6/4/18 7:41 AM, li.jiang at oracle.com wrote:
>>> Hi Naoto,
>>>
>>> Pls review the updated code:
>>>
>>> http://cr.openjdk.java.net/~ljiang/8202026/webrev.02/
>>>
>>> - As suggested, clean up the old transition dates.
>>> - Update copyright year.
>>> - ISO 4217 Amendment #167 was published today, which discards the 
>>> #166, so withdraw the change for #166 in webrev.02.
>>>
>>> Bug for #167:
>>> https://bugs.openjdk.java.net/browse/JDK-8204269
>>>
>>> Test passed on mach5.
>>>
>>> Thanks,
>>> Leo
>>>
>>> On 26/04/2018 1:00 AM, naoto.sato at oracle.com wrote:
>>>> Hi Leo,
>>>>
>>>> Although JDK11 is slated in 09/2018, enabling amendment 166 now is 
>>>> technically a bug, as it will be effective from June 4. Please use 
>>>> the transition mechanism in 
>>>> make/data/currency/CurrencyData.properties and 
>>>> test/jdk/java/util/Currency/tablea1.txt.
>>>>
>>>> OTOH, there are old (past) transition entries. I would clean up 
>>>> those entries, such as:
>>>>
>>>> ??326 # LATVIA
>>>> ??327 LV=LVL;2013-12-31-22-00-00;EUR
>>>>
>>>> in CurrencyData.properties. This applies to tabela1.txt as well.
>>>>
>>>> Naoto
>>>>
>>>> On 4/24/18 8:52 PM, Leo Jiang wrote:
>>>>> Forgot to mention, the tests in Currency fold are passed on Mach5.
>>>>>
>>>>> -Leo
>>>>>
>>>>> On 04/25/2018 09:33 AM, Leo Jiang wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Please review the changes to address the ISO 4217 Amendment 165 
>>>>>> 166 update.
>>>>>>
>>>>>> Bug:
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8193552? 165
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8202026? 166
>>>>>>
>>>>>> CR:
>>>>>> http://cr.openjdk.java.net/~ljiang/8202026/webrev.00/
>>>>>>
>>>>>>
>>>>>> Detail:
>>>>>> #165
>>>>>> From:
>>>>>> MAURITANIA??? Ouguiya??? MRO??? 478??? 2
>>>>>> To:
>>>>>> MAURITANIA??? Ouguiya??? MRU??? 929??? 2
>>>>>>
>>>>>> #166
>>>>>> From:
>>>>>> VENEZUELA (BOLIVARIAN REPUBLIC OF)??? Bol?var??? VEF??? 937??? 2
>>>>>> To:
>>>>>> VENEZUELA (BOLIVARIAN REPUBLIC OF)??? Bol?var Soberano??? VES 
>>>>>> 928??? 2
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> Leo

From naoto.sato at oracle.com  Tue Jun  5 17:14:10 2018
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 5 Jun 2018 10:14:10 -0700
Subject: <i18n dev> RFR JDK-8203872: Upgrading JDK with latest available
 LSR data from IANA
In-Reply-To: <6aa57b43-c15e-cfee-cb32-922e4eec8489@oracle.com>
References: <6aa57b43-c15e-cfee-cb32-922e4eec8489@oracle.com>
Message-ID: <623bc32c-5a6e-b4a4-985b-d832e17af203@oracle.com>

Looks good.

Naoto

On 6/4/18 10:13 PM, Nishit Jain wrote:
> Hi,
> 
> Please review the fix for JDK-8203872.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8203872
> Webrev: http://cr.openjdk.java.net/~nishjain/8203872/webrev.01/
> 
> Fix: Updated the LSR data to the version 2017-08-15
> 
> Regards,
> Nishit Jain

From christoph.langer at sap.com  Thu Jun  7 12:16:49 2018
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 7 Jun 2018 12:16:49 +0000
Subject: <i18n dev> JDK-8201429 - Support AIX Input Method Editor (IME)
 for AWT Input Method Framework (IMF)
In-Reply-To: <6d1ccc44-d87e-f82d-fd47-7ffe6e6879ce@oracle.com>
References: <e092f07395544dba931102a3e0bf507d@sap.com>
 <88053947-97d2-58f8-2d5c-a980a0e11448@oracle.com>
 <363f390f-4fec-8400-ddf7-cb8058101dd6@oracle.com>
 <6d1ccc44-d87e-f82d-fd47-7ffe6e6879ce@oracle.com>
Message-ID: <f49c5bd303f74c7183ffb8b03a30bc71@sap.com>

Hi Naoto,

I think I understand what you say, though only one class extending X11InputMethod currently exists, which is sun/awt/X11/XInputMethod.

Probably the code could be refactored such that X11InputMethodBase gets renamed back to X11InputMethod and the coding that went to the platform specific implementations of X11InputMethod with our change should move further down to platform specific implementations of sun/awt/X11/XInputMethod. Is that what you mean?

Best regards
Christoph

> -----Original Message-----
> From: naoto.sato at oracle.com [mailto:naoto.sato at oracle.com]
> Sent: Freitag, 1. Juni 2018 18:12
> To: Phil Race <philip.race at oracle.com>; Langer, Christoph
> <christoph.langer at sap.com>; i18n-dev at openjdk.java.net
> Cc: Ichiroh Takiguchi <takiguc at linux.vnet.ibm.com>
> Subject: Re: <i18n dev> JDK-8201429 - Support AIX Input Method Editor
> (IME) for AWT Input Method Framework (IMF)
> 
> The issue in the current naming scheme (sharing the same class name for
> impls) is that it assumes one X11 im impl per *platform*. Same
> IMs/WindowManagers can be shared across platforms, or one platform can
> have multiple IM/WM (e.g., the example I wrote below MAWT/XAWT
> co-exist), and the current design cannot deal with these situations.
> 
> Naoto
> 
> On 5/30/18 2:33 PM, Phil Race wrote:
> > It is in a platform dependent directory .. and I gather this allows the
> > build to pick up the right one
> > without any work here.
> >
> > -phil
> >
> > On 5/30/2018 2:08 PM, Naoto Sato wrote:
> >> Hi,
> >>
> >> I see that the change introduced the base abstraction class,
> >> X11InputMethodBase. Back in the days I worked on it, X11InputMethod is
> >> the base abstract class, and platform impls. have names representing
> >> them, i.e, MInputMethod for Motif, and XInputMethod for XAWT. Now
> >> X11InputMethod is a platform dependent implementation. It'd be a bit
> >> clearer to use the different impl class names.
> >>
> >> Naoto
> >>
> >> On 5/30/18 1:27 PM, Langer, Christoph wrote:
> >>> Hi,
> >>>
> >>> I was just asked to include i18-n dev in the review of the change for
> >>> this Item.
> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201429
> >>>
> >>> Last webrev: http://cr.openjdk.java.net/~clanger/webrevs/8201429.3/
> >>>
> >>> Unfortunately this request came a bit too late and the change has
> >>> already been pushed:
> >>> http://hg.openjdk.java.net/jdk/client/rev/668463f93ec0
> >>>
> >>> So this is now merely a notification. However, maybe you can still
> >>> have an eye on this or even do some specific testing. In case you see
> >>> some issue with it, we shall open a follow-up item.
> >>>
> >>> Thanks
> >>> Christoph
> >>>
> >

From naoto.sato at oracle.com  Thu Jun  7 16:18:01 2018
From: naoto.sato at oracle.com (Naoto Sato)
Date: Thu, 7 Jun 2018 09:18:01 -0700
Subject: <i18n dev> JDK-8201429 - Support AIX Input Method Editor (IME)
 for AWT Input Method Framework (IMF)
In-Reply-To: <f49c5bd303f74c7183ffb8b03a30bc71@sap.com>
References: <e092f07395544dba931102a3e0bf507d@sap.com>
 <88053947-97d2-58f8-2d5c-a980a0e11448@oracle.com>
 <363f390f-4fec-8400-ddf7-cb8058101dd6@oracle.com>
 <6d1ccc44-d87e-f82d-fd47-7ffe6e6879ce@oracle.com>
 <f49c5bd303f74c7183ffb8b03a30bc71@sap.com>
Message-ID: <477e50d4-774e-d83f-68a5-d9f51404b514@oracle.com>

Hi Christoph,

Yes, that's exactly what I meant by the previous email.

Naoto

On 6/7/18 5:16 AM, Langer, Christoph wrote:
> Hi Naoto,
> 
> I think I understand what you say, though only one class extending X11InputMethod currently exists, which is sun/awt/X11/XInputMethod.
> 
> Probably the code could be refactored such that X11InputMethodBase gets renamed back to X11InputMethod and the coding that went to the platform specific implementations of X11InputMethod with our change should move further down to platform specific implementations of sun/awt/X11/XInputMethod. Is that what you mean?
> 
> Best regards
> Christoph
> 
>> -----Original Message-----
>> From: naoto.sato at oracle.com [mailto:naoto.sato at oracle.com]
>> Sent: Freitag, 1. Juni 2018 18:12
>> To: Phil Race <philip.race at oracle.com>; Langer, Christoph
>> <christoph.langer at sap.com>; i18n-dev at openjdk.java.net
>> Cc: Ichiroh Takiguchi <takiguc at linux.vnet.ibm.com>
>> Subject: Re: <i18n dev> JDK-8201429 - Support AIX Input Method Editor
>> (IME) for AWT Input Method Framework (IMF)
>>
>> The issue in the current naming scheme (sharing the same class name for
>> impls) is that it assumes one X11 im impl per *platform*. Same
>> IMs/WindowManagers can be shared across platforms, or one platform can
>> have multiple IM/WM (e.g., the example I wrote below MAWT/XAWT
>> co-exist), and the current design cannot deal with these situations.
>>
>> Naoto
>>
>> On 5/30/18 2:33 PM, Phil Race wrote:
>>> It is in a platform dependent directory .. and I gather this allows the
>>> build to pick up the right one
>>> without any work here.
>>>
>>> -phil
>>>
>>> On 5/30/2018 2:08 PM, Naoto Sato wrote:
>>>> Hi,
>>>>
>>>> I see that the change introduced the base abstraction class,
>>>> X11InputMethodBase. Back in the days I worked on it, X11InputMethod is
>>>> the base abstract class, and platform impls. have names representing
>>>> them, i.e, MInputMethod for Motif, and XInputMethod for XAWT. Now
>>>> X11InputMethod is a platform dependent implementation. It'd be a bit
>>>> clearer to use the different impl class names.
>>>>
>>>> Naoto
>>>>
>>>> On 5/30/18 1:27 PM, Langer, Christoph wrote:
>>>>> Hi,
>>>>>
>>>>> I was just asked to include i18-n dev in the review of the change for
>>>>> this Item.
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201429
>>>>>
>>>>> Last webrev: http://cr.openjdk.java.net/~clanger/webrevs/8201429.3/
>>>>>
>>>>> Unfortunately this request came a bit too late and the change has
>>>>> already been pushed:
>>>>> http://hg.openjdk.java.net/jdk/client/rev/668463f93ec0
>>>>>
>>>>> So this is now merely a notification. However, maybe you can still
>>>>> have an eye on this or even do some specific testing. In case you see
>>>>> some issue with it, we shall open a follow-up item.
>>>>>
>>>>> Thanks
>>>>> Christoph
>>>>>
>>>

From dipak.kumar at oracle.com  Fri Jun  8 05:13:08 2018
From: dipak.kumar at oracle.com (Dipak Kumar)
Date: Thu, 7 Jun 2018 22:13:08 -0700 (PDT)
Subject: <i18n dev> [11] Review Request: 8202696 glyphs in textfield
 only shown when thai baht-character is added
In-Reply-To: <17242fed-e6e7-4238-9856-229799ddce1e@default>
References: <17242fed-e6e7-4238-9856-229799ddce1e@default>
Message-ID: <be7a3eab-c8ac-44d9-a028-b3ec7bad1002@default>

Just a gentle reminder to look into below review request.

Thanks,
Dipak

-----Original Message-----
From: Dipak Kumar 
Sent: 05 June 2018 12:03
To: 2d-dev at openjdk.java.net; i18n-dev at openjdk.java.net; Philip Race <philip.race at oracle.com>; Naoto Sato <naoto.sato at oracle.com>
Subject: [11] Review Request: 8202696 glyphs in textfield only shown when thai baht-character is added

Hi,

Please review below fix :

Bug: https://bugs.openjdk.java.net/browse/JDK-8202696 
Webrev: http://cr.openjdk.java.net/~dkumar/8202696/webrev.00/ 

Characters which are not getting displayed actually belong to Phonetic Extensions (https://en.wikipedia.org/wiki/Phonetic_Extensions ).
These characters are not getting rendered properly because they are in exclusion range mentioned in the windows.fontconfig.properties file.
In the above fix, font exclusion ranges have been adjusted so that these characters do not fall within these ranges

Font related Jtreg tests and Mach5 client tests are fine.

Thanks,
Dipak

From philip.race at oracle.com  Tue Jun 12 20:46:28 2018
From: philip.race at oracle.com (Phil Race)
Date: Tue, 12 Jun 2018 13:46:28 -0700
Subject: <i18n dev> [11] Review Request: 8202696 glyphs in textfield
 only shown when thai baht-character is added
In-Reply-To: <17242fed-e6e7-4238-9856-229799ddce1e@default>
References: <17242fed-e6e7-4238-9856-229799ddce1e@default>
Message-ID: <6cd561e0-fd18-b3ba-7934-57e4cba61441@oracle.com>

I can only guess why this range was excluded.
My guess is that it was something to do with an attempt at
allowing as many of these glyphs as possible to come from
(for example) a Chinese font in a chinese locale even though we
always put the latin font first ..

The interesting reason why adding a Thai Baht magically makes them
appears is Thai forces TextLayout .. and it (apparently) bypasses the 
exclusion range.
I suspect this is because layout needs to operate on physical fonts so 
gets the list
of physical fonts and operates on these explicitly bypassing 
CompositeFont which
is where this support exists.
You can prove that just by using one of these phonetic chars in 
Font2DTest without
adding Thai or anything else and switching to TextLayout .. lo and 
behold .. it appears.
I wonder how long that has been the case ? Perhaps so long as to be 
effectively forever ..

That makes a case for getting rid of all these ranges.
The use for the ranges is to control what physical font is used for 
glyphs in cases
where some font that may be "earlier" in the list supplies glyphs that 
you'd actually
prefer to come from some other font.
That may be useful if the exclusion ranges were able to be applied depending
on your locale, but this alphabetic exclusion is particularly questionable.

So the change is OK, but can't the test be automated .. and headless ?
You just need to do something like ask if the font "canDisplay()" these 
code points.
However the test is fragile in the sense that it assumes that logical 
fonts on
Windows are capable of supporting them.

-phil


On 06/04/2018 11:32 PM, Dipak Kumar wrote:
> Hi,
>
> Please review below fix :
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8202696
> Webrev: http://cr.openjdk.java.net/~dkumar/8202696/webrev.00/
>
> Characters which are not getting displayed actually belong to Phonetic Extensions (https://en.wikipedia.org/wiki/Phonetic_Extensions ).
> These characters are not getting rendered properly because they are in exclusion range mentioned in the windows.fontconfig.properties file.
> In the above fix, font exclusion ranges have been adjusted so that these characters do not fall within these ranges
>
> Font related Jtreg tests and Mach5 client tests are fine.
>
> Thanks,
> Dipak


From philip.race at oracle.com  Tue Jun 12 21:55:45 2018
From: philip.race at oracle.com (Phil Race)
Date: Tue, 12 Jun 2018 14:55:45 -0700
Subject: <i18n dev> [11] Review Request: 8202696 glyphs in textfield
 only shown when thai baht-character is added
In-Reply-To: <6cd561e0-fd18-b3ba-7934-57e4cba61441@oracle.com>
References: <17242fed-e6e7-4238-9856-229799ddce1e@default>
 <6cd561e0-fd18-b3ba-7934-57e4cba61441@oracle.com>
Message-ID: <040f59ee-9c9f-58fb-3b6d-5b2aad3181bf@oracle.com>

BTW I think the synopsis really needs updating !

Once you know what is going on, continuing to title it after the random
empirical observation of the reporter is not necessary. I've changed it to :

"Remove exclusion range for phonetic chars in windows fontconfig.properties"

Please use that in the commit - when you get to it.

-phil.

On 06/12/2018 01:46 PM, Phil Race wrote:
> I can only guess why this range was excluded.
> My guess is that it was something to do with an attempt at
> allowing as many of these glyphs as possible to come from
> (for example) a Chinese font in a chinese locale even though we
> always put the latin font first ..
>
> The interesting reason why adding a Thai Baht magically makes them
> appears is Thai forces TextLayout .. and it (apparently) bypasses the 
> exclusion range.
> I suspect this is because layout needs to operate on physical fonts so 
> gets the list
> of physical fonts and operates on these explicitly bypassing 
> CompositeFont which
> is where this support exists.
> You can prove that just by using one of these phonetic chars in 
> Font2DTest without
> adding Thai or anything else and switching to TextLayout .. lo and 
> behold .. it appears.
> I wonder how long that has been the case ? Perhaps so long as to be 
> effectively forever ..
>
> That makes a case for getting rid of all these ranges.
> The use for the ranges is to control what physical font is used for 
> glyphs in cases
> where some font that may be "earlier" in the list supplies glyphs that 
> you'd actually
> prefer to come from some other font.
> That may be useful if the exclusion ranges were able to be applied 
> depending
> on your locale, but this alphabetic exclusion is particularly 
> questionable.
>
> So the change is OK, but can't the test be automated .. and headless ?
> You just need to do something like ask if the font "canDisplay()" 
> these code points.
> However the test is fragile in the sense that it assumes that logical 
> fonts on
> Windows are capable of supporting them.
>
> -phil
>
>
> On 06/04/2018 11:32 PM, Dipak Kumar wrote:
>> Hi,
>>
>> Please review below fix :
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8202696
>> Webrev: http://cr.openjdk.java.net/~dkumar/8202696/webrev.00/
>>
>> Characters which are not getting displayed actually belong to 
>> Phonetic Extensions 
>> (https://en.wikipedia.org/wiki/Phonetic_Extensions ).
>> These characters are not getting rendered properly because they are 
>> in exclusion range mentioned in the windows.fontconfig.properties file.
>> In the above fix, font exclusion ranges have been adjusted so that 
>> these characters do not fall within these ranges
>>
>> Font related Jtreg tests and Mach5 client tests are fine.
>>
>> Thanks,
>> Dipak
>


From rachna.goel at oracle.com  Wed Jun 13 05:33:49 2018
From: rachna.goel at oracle.com (Rachna Goel)
Date: Wed, 13 Jun 2018 11:03:49 +0530
Subject: <i18n dev> RFR: [11] 8202537: CLDR 33
Message-ID: <1ba7ab6d-d1d7-7c06-1b3e-1f9665cbe61a@oracle.com>

Hi,

Kindly review fix for JDK-8202537. Fix is to upgrade Unicode 
consortium's CLDR data into JDK from current version 29 to 33.

For more info : http://cldr.unicode.org/index/downloads/cldr-33

Bug : https://bugs.openjdk.java.net/browse/JDK-8202537

Patch: http://cr.openjdk.java.net/~rgoel/JDK-8202537/webrev.06/index.html

-- 
Thanks,
Rachna


From naoto.sato at oracle.com  Wed Jun 13 17:03:23 2018
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Wed, 13 Jun 2018 10:03:23 -0700
Subject: <i18n dev> RFR: [11] 8202537: CLDR 33
In-Reply-To: <1ba7ab6d-d1d7-7c06-1b3e-1f9665cbe61a@oracle.com>
References: <1ba7ab6d-d1d7-7c06-1b3e-1f9665cbe61a@oracle.com>
Message-ID: <d211a3f7-6fc6-b048-2e3c-a03365af6c36@oracle.com>

Hi Rachna,

A couple of comments:

- NumberingSystemsParseHandler.java

Since the code substitutes latin digits for supplementary digits, it can 
skip line 68-79.

- A test should be written for the above substitution.

Naoto

On 6/12/18 10:33 PM, Rachna Goel wrote:
> Hi,
> 
> Kindly review fix for JDK-8202537. Fix is to upgrade Unicode 
> consortium's CLDR data into JDK from current version 29 to 33.
> 
> For more info : http://cldr.unicode.org/index/downloads/cldr-33
> 
> Bug : https://bugs.openjdk.java.net/browse/JDK-8202537
> 
> Patch: http://cr.openjdk.java.net/~rgoel/JDK-8202537/webrev.06/index.html
> 

From dipak.kumar at oracle.com  Thu Jun 14 07:07:49 2018
From: dipak.kumar at oracle.com (Dipak Kumar)
Date: Thu, 14 Jun 2018 00:07:49 -0700 (PDT)
Subject: <i18n dev> [11] Review Request: 8202696 glyphs in textfield
 only shown when thai baht-character is added
In-Reply-To: <040f59ee-9c9f-58fb-3b6d-5b2aad3181bf@oracle.com>
References: <17242fed-e6e7-4238-9856-229799ddce1e@default>
 <6cd561e0-fd18-b3ba-7934-57e4cba61441@oracle.com>
 <040f59ee-9c9f-58fb-3b6d-5b2aad3181bf@oracle.com>
Message-ID: <ce47c811-8fe8-4bcf-923e-c0172992cf5e@default>

Hi Phil,

Thanks for reviewing the patch and providing useful information.
Regarding your suggestion of using "canDisplay()" in test, I tried using this function to make the test headless. 
But this function is returning true even without proposed fix in fontconfig.properties file. Font exclusion is not coming into picture in this function call.

In the previously written test case, I have added a check for font support (whether characters can be displayed or not using function "canDisplayUpTo()").
Please find the updated webrev at http://cr.openjdk.java.net/~dkumar/8202696/webrev.01/ .

Request you to have a look into this again and let me know your inputs.

Many thanks,
Dipak

-----Original Message-----
From: Phil Race 
Sent: 13 June 2018 03:26
To: Dipak Kumar <dipak.kumar at oracle.com>; 2d-dev at openjdk.java.net; i18n-dev at openjdk.java.net; Naoto Sato <naoto.sato at oracle.com>
Subject: Re: [11] Review Request: 8202696 glyphs in textfield only shown when thai baht-character is added

BTW I think the synopsis really needs updating !

Once you know what is going on, continuing to title it after the random empirical observation of the reporter is not necessary. I've changed it to :

"Remove exclusion range for phonetic chars in windows fontconfig.properties"

Please use that in the commit - when you get to it.

-phil.

On 06/12/2018 01:46 PM, Phil Race wrote:
> I can only guess why this range was excluded.
> My guess is that it was something to do with an attempt at allowing as 
> many of these glyphs as possible to come from (for example) a Chinese 
> font in a chinese locale even though we always put the latin font 
> first ..
>
> The interesting reason why adding a Thai Baht magically makes them 
> appears is Thai forces TextLayout .. and it (apparently) bypasses the 
> exclusion range.
> I suspect this is because layout needs to operate on physical fonts so 
> gets the list of physical fonts and operates on these explicitly 
> bypassing CompositeFont which is where this support exists.
> You can prove that just by using one of these phonetic chars in 
> Font2DTest without adding Thai or anything else and switching to 
> TextLayout .. lo and behold .. it appears.
> I wonder how long that has been the case ? Perhaps so long as to be 
> effectively forever ..
>
> That makes a case for getting rid of all these ranges.
> The use for the ranges is to control what physical font is used for 
> glyphs in cases where some font that may be "earlier" in the list 
> supplies glyphs that you'd actually prefer to come from some other 
> font.
> That may be useful if the exclusion ranges were able to be applied 
> depending on your locale, but this alphabetic exclusion is 
> particularly questionable.
>
> So the change is OK, but can't the test be automated .. and headless ?
> You just need to do something like ask if the font "canDisplay()" 
> these code points.
> However the test is fragile in the sense that it assumes that logical 
> fonts on Windows are capable of supporting them.
>
> -phil
>
>
> On 06/04/2018 11:32 PM, Dipak Kumar wrote:
>> Hi,
>>
>> Please review below fix :
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8202696
>> Webrev: http://cr.openjdk.java.net/~dkumar/8202696/webrev.00/
>>
>> Characters which are not getting displayed actually belong to 
>> Phonetic Extensions 
>> (https://en.wikipedia.org/wiki/Phonetic_Extensions ).
>> These characters are not getting rendered properly because they are 
>> in exclusion range mentioned in the windows.fontconfig.properties file.
>> In the above fix, font exclusion ranges have been adjusted so that 
>> these characters do not fall within these ranges
>>
>> Font related Jtreg tests and Mach5 client tests are fine.
>>
>> Thanks,
>> Dipak
>


From rachna.goel at oracle.com  Thu Jun 14 14:01:55 2018
From: rachna.goel at oracle.com (Rachna Goel)
Date: Thu, 14 Jun 2018 19:31:55 +0530
Subject: <i18n dev> RFR: [11] 8202537: CLDR 33
In-Reply-To: <d211a3f7-6fc6-b048-2e3c-a03365af6c36@oracle.com>
References: <1ba7ab6d-d1d7-7c06-1b3e-1f9665cbe61a@oracle.com>
 <d211a3f7-6fc6-b048-2e3c-a03365af6c36@oracle.com>
Message-ID: <2cc825ca-35e3-de95-e233-4444158e32c2@oracle.com>

Hi Naoto,

Thanks a lot for the review.

I have made suggested changes, Kindly have a look at : 
http://cr.openjdk.java.net/~rgoel/JDK-8202537/webrev.07/

- Updated NumberingSystemsParseHandler.java

- Updated LocaleData.cldr for new test case.

Thanks,

Rachna


On 6/13/18 10:33 PM, naoto.sato at oracle.com wrote:
> Hi Rachna,
>
> A couple of comments:
>
> - NumberingSystemsParseHandler.java
>
> Since the code substitutes latin digits for supplementary digits, it 
> can skip line 68-79.
>
> - A test should be written for the above substitution.
>
> Naoto
>
> On 6/12/18 10:33 PM, Rachna Goel wrote:
>> Hi,
>>
>> Kindly review fix for JDK-8202537. Fix is to upgrade Unicode 
>> consortium's CLDR data into JDK from current version 29 to 33.
>>
>> For more info : http://cldr.unicode.org/index/downloads/cldr-33
>>
>> Bug : https://bugs.openjdk.java.net/browse/JDK-8202537
>>
>> Patch: 
>> http://cr.openjdk.java.net/~rgoel/JDK-8202537/webrev.06/index.html
>>

-- 
Thanks,
Rachna


From philip.race at oracle.com  Thu Jun 14 17:26:54 2018
From: philip.race at oracle.com (Phil Race)
Date: Thu, 14 Jun 2018 10:26:54 -0700
Subject: <i18n dev> <AWT Dev> Proposal: Windows IME related patch
In-Reply-To: <c8cc78edbcc0c10145e4844805faa2e9@linux.vnet.ibm.com>
References: <c8cc78edbcc0c10145e4844805faa2e9@linux.vnet.ibm.com>
Message-ID: <d114ee98-9776-ef14-2264-04d1b52258fe@oracle.com>

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  Thu Jun 14 19:42:54 2018
From: naoto.sato at oracle.com (Naoto Sato)
Date: Thu, 14 Jun 2018 12:42:54 -0700
Subject: <i18n dev> RFR: [11] 8202537: CLDR 33
In-Reply-To: <2cc825ca-35e3-de95-e233-4444158e32c2@oracle.com>
References: <1ba7ab6d-d1d7-7c06-1b3e-1f9665cbe61a@oracle.com>
 <d211a3f7-6fc6-b048-2e3c-a03365af6c36@oracle.com>
 <2cc825ca-35e3-de95-e233-4444158e32c2@oracle.com>
Message-ID: <7b670a7b-654a-273c-6ef8-50a087006c3b@oracle.com>

Looks good to me.

Naoto

On 6/14/18 7:01 AM, Rachna Goel wrote:
> Hi Naoto,
> 
> Thanks a lot for the review.
> 
> I have made suggested changes, Kindly have a look at : 
> http://cr.openjdk.java.net/~rgoel/JDK-8202537/webrev.07/
> 
> - Updated NumberingSystemsParseHandler.java
> 
> - Updated LocaleData.cldr for new test case.
> 
> Thanks,
> 
> Rachna
> 
> 
> On 6/13/18 10:33 PM, naoto.sato at oracle.com wrote:
>> Hi Rachna,
>>
>> A couple of comments:
>>
>> - NumberingSystemsParseHandler.java
>>
>> Since the code substitutes latin digits for supplementary digits, it 
>> can skip line 68-79.
>>
>> - A test should be written for the above substitution.
>>
>> Naoto
>>
>> On 6/12/18 10:33 PM, Rachna Goel wrote:
>>> Hi,
>>>
>>> Kindly review fix for JDK-8202537. Fix is to upgrade Unicode 
>>> consortium's CLDR data into JDK from current version 29 to 33.
>>>
>>> For more info : http://cldr.unicode.org/index/downloads/cldr-33
>>>
>>> Bug : https://bugs.openjdk.java.net/browse/JDK-8202537
>>>
>>> Patch: 
>>> http://cr.openjdk.java.net/~rgoel/JDK-8202537/webrev.06/index.html
>>>
> 
> -- 
> Thanks,
> Rachna
> 

From TOSHIONA at jp.ibm.com  Fri Jun 15 09:10:14 2018
From: TOSHIONA at jp.ibm.com (Toshio 5 Nakamura)
Date: Fri, 15 Jun 2018 18:10:14 +0900
Subject: <i18n dev> JDK-8042131: Proposal of Mapped-values formatter for
	non-IsoChronology
Message-ID: <OF16D580D1.91376F0E-ON002582AD.0031634A-492582AD.0032605D@notes.na.collabserv.com>


Hello core-libs and i18n folks,

We'd like to request to reconsider JDK-8042131,
"DateTimeFormatterBuilder Mapped-values do not work for JapaneseDate".
The report was posted by our team long time ago, and was closed as not an
issue.
At that time, the feature was for only IsoChronology.

Now, I found the attached patch can activate the mapped-values formatter
for
non-IsoChronology.

Additionally, the Japanese new era will be expected in May 2019. The first
year of
each era has a special expression in Japanese, "U+5143 U+5e74" (Gannen).
java.util.JapaneseImperialCalendar uses this expression.
We'd like to use the expression with JapaneseChronology by mapped-values
formatter as an option.

Can we have a sponsor of this proposal?

--sample usage of Japanese new era--
DateTimeFormatterBuilder builder = new DateTimeFormatterBuilder();
Map<Long, String> yearMap = new HashMap<>();
yearMap.put(1L, "\u5143");
builder.appendText(ChronoField.ERA, TextStyle.FULL)
            .appendText(ChronoField.YEAR_OF_ERA, yearMap)
            .appendLiteral("\u5e74");
---------------

Report:
https://bugs.openjdk.java.net/browse/JDK-8042131

Patch:
--- old/src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java	2018-06-15 17:39:11.489303979 +0900
+++ new/src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java	2018-06-15 17:39:11.157303972 +0900
@@ -793,6 +793,11 @@
         final LocaleStore store = new LocaleStore(map);
         DateTimeTextProvider provider = new DateTimeTextProvider() {
             @Override
+            public String getText(Chronology chrono, TemporalField field,
+                                  long value, TextStyle style, Locale locale) {
+                return store.getText(value, style);
+            }
+            @Override
             public String getText(TemporalField field, long value, TextStyle style, Locale locale) {
                 return store.getText(value, style);
             }
--- old/test/jdk/java/time/test/java/time/format/TestDateTimeFormatterBuilderWithLocale.java	2018-06-15 17:39:12.664304007 +0900
+++ new/test/jdk/java/time/test/java/time/format/TestDateTimeFormatterBuilderWithLocale.java	2018-06-15 17:39:12.298303999 +0900
@@ -67,14 +67,21 @@
 import java.time.chrono.Chronology;
 import java.time.chrono.IsoChronology;
 import java.time.chrono.JapaneseChronology;
+import java.time.chrono.JapaneseEra;
 import java.time.chrono.MinguoChronology;
+import java.time.chrono.ThaiBuddhistChronology;
+import java.time.chrono.ChronoLocalDate;
 import java.time.format.DateTimeFormatter;
 import java.time.format.DateTimeFormatterBuilder;
 import java.time.format.FormatStyle;
 import java.time.LocalDate;
 import java.time.temporal.Temporal;
+import java.time.temporal.ChronoField;
+import static java.time.temporal.ChronoUnit.YEARS;

 import java.util.Locale;
+import java.util.Map;
+import java.util.HashMap;

 import static org.testng.Assert.assertEquals;

@@ -115,6 +122,31 @@
     }

     //-----------------------------------------------------------------------
+    @DataProvider(name="mappedPatterns")
+    Object[][] localizedMappedPatterns() {
+        return new Object[][] {
+            {IsoChronology.INSTANCE.date(1,1,1), Locale.ENGLISH},
+            {JapaneseChronology.INSTANCE.date(JapaneseEra.HEISEI,
+                                              1,1,8), Locale.ENGLISH},
+            {MinguoChronology.INSTANCE.date(1,1,1), Locale.ENGLISH},
+            {ThaiBuddhistChronology.INSTANCE.date(1,1,1), Locale.ENGLISH},
+        };
+    }
+
+    @Test(dataProvider="mappedPatterns")
+    public void test_getLocalizedMappedPattern(ChronoLocalDate date, Locale locale) {
+        final String new1st = "1st";
+        Map<Long, String> yearMap = new HashMap<>();
+        yearMap.put(1L, new1st);
+        DateTimeFormatterBuilder builder = new DateTimeFormatterBuilder();
+        builder.appendText(ChronoField.YEAR_OF_ERA, yearMap);
+
+        String actual = date.format(builder.toFormatter(locale));
+        assertEquals(actual, new1st);
+    }
+
+
+    //-----------------------------------------------------------------------
     @DataProvider(name="localePatterns")
     Object[][] localizedDateTimePatterns() {
         return new Object[][] {

---
Best regards,
Toshio Nakamura, IBM Japan

From philip.race at oracle.com  Fri Jun 15 18:41:02 2018
From: philip.race at oracle.com (Phil Race)
Date: Fri, 15 Jun 2018 11:41:02 -0700
Subject: <i18n dev> [11] Review Request: 8202696 glyphs in textfield
 only shown when thai baht-character is added
In-Reply-To: <ce47c811-8fe8-4bcf-923e-c0172992cf5e@default>
References: <17242fed-e6e7-4238-9856-229799ddce1e@default>
 <6cd561e0-fd18-b3ba-7934-57e4cba61441@oracle.com>
 <040f59ee-9c9f-58fb-3b6d-5b2aad3181bf@oracle.com>
 <ce47c811-8fe8-4bcf-923e-c0172992cf5e@default>
Message-ID: <96579ce3-b499-15bf-1787-97f33113f23d@oracle.com>

The exclusion ranges only apply to the logical fonts, so the iteration you
are doing looking for any font is now not testing the case you are 
trying to fix,
except by chance. You will need to limit the iteration to the logical fonts.

I don't know why canDisplay(..) did not do what I would expect .. 
particularly
since canDisplayUpTo should be using the same information.

-phil.

On 06/14/2018 12:07 AM, Dipak Kumar wrote:
> Hi Phil,
>
> Thanks for reviewing the patch and providing useful information.
> Regarding your suggestion of using "canDisplay()" in test, I tried using this function to make the test headless.
> But this function is returning true even without proposed fix in fontconfig.properties file. Font exclusion is not coming into picture in this function call.
>
> In the previously written test case, I have added a check for font support (whether characters can be displayed or not using function "canDisplayUpTo()").
> Please find the updated webrev at http://cr.openjdk.java.net/~dkumar/8202696/webrev.01/ .
>
> Request you to have a look into this again and let me know your inputs.
>
> Many thanks,
> Dipak
>
> -----Original Message-----
> From: Phil Race
> Sent: 13 June 2018 03:26
> To: Dipak Kumar <dipak.kumar at oracle.com>; 2d-dev at openjdk.java.net; i18n-dev at openjdk.java.net; Naoto Sato <naoto.sato at oracle.com>
> Subject: Re: [11] Review Request: 8202696 glyphs in textfield only shown when thai baht-character is added
>
> BTW I think the synopsis really needs updating !
>
> Once you know what is going on, continuing to title it after the random empirical observation of the reporter is not necessary. I've changed it to :
>
> "Remove exclusion range for phonetic chars in windows fontconfig.properties"
>
> Please use that in the commit - when you get to it.
>
> -phil.
>
> On 06/12/2018 01:46 PM, Phil Race wrote:
>> I can only guess why this range was excluded.
>> My guess is that it was something to do with an attempt at allowing as
>> many of these glyphs as possible to come from (for example) a Chinese
>> font in a chinese locale even though we always put the latin font
>> first ..
>>
>> The interesting reason why adding a Thai Baht magically makes them
>> appears is Thai forces TextLayout .. and it (apparently) bypasses the
>> exclusion range.
>> I suspect this is because layout needs to operate on physical fonts so
>> gets the list of physical fonts and operates on these explicitly
>> bypassing CompositeFont which is where this support exists.
>> You can prove that just by using one of these phonetic chars in
>> Font2DTest without adding Thai or anything else and switching to
>> TextLayout .. lo and behold .. it appears.
>> I wonder how long that has been the case ? Perhaps so long as to be
>> effectively forever ..
>>
>> That makes a case for getting rid of all these ranges.
>> The use for the ranges is to control what physical font is used for
>> glyphs in cases where some font that may be "earlier" in the list
>> supplies glyphs that you'd actually prefer to come from some other
>> font.
>> That may be useful if the exclusion ranges were able to be applied
>> depending on your locale, but this alphabetic exclusion is
>> particularly questionable.
>>
>> So the change is OK, but can't the test be automated .. and headless ?
>> You just need to do something like ask if the font "canDisplay()"
>> these code points.
>> However the test is fragile in the sense that it assumes that logical
>> fonts on Windows are capable of supporting them.
>>
>> -phil
>>
>>
>> On 06/04/2018 11:32 PM, Dipak Kumar wrote:
>>> Hi,
>>>
>>> Please review below fix :
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8202696
>>> Webrev: http://cr.openjdk.java.net/~dkumar/8202696/webrev.00/
>>>
>>> Characters which are not getting displayed actually belong to
>>> Phonetic Extensions
>>> (https://en.wikipedia.org/wiki/Phonetic_Extensions ).
>>> These characters are not getting rendered properly because they are
>>> in exclusion range mentioned in the windows.fontconfig.properties file.
>>> In the above fix, font exclusion ranges have been adjusted so that
>>> these characters do not fall within these ranges
>>>
>>> Font related Jtreg tests and Mach5 client tests are fine.
>>>
>>> Thanks,
>>> Dipak


From naoto.sato at oracle.com  Fri Jun 15 22:14:47 2018
From: naoto.sato at oracle.com (Naoto Sato)
Date: Fri, 15 Jun 2018 15:14:47 -0700
Subject: <i18n dev> [11] RFR: 8042131: DateTimeFormatterBuilder
 Mapped-values do not work for JapaneseDate
Message-ID: <9018eeda-d891-adf8-81b7-ef1d1db08281@oracle.com>

Hello,

Please review the fix to the following issue:

https://bugs.openjdk.java.net/browse/JDK-8042131

The proposed change is located at:

http://cr.openjdk.java.net/~naoto/8042131/webrev.00/

The fix is originally contributedy by Toshio Nakamura at IBM [1]. I am 
sponsoring the fix, with some trivial modifications to the test (diff is 
attached).

Naoto

[1] 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-June/053830.html
-------------- next part --------------
diff -r 9b997bfc60d5 test/jdk/java/time/test/java/time/format/TestDateTimeFormatterBuilderWithLocale.java
--- a/test/jdk/java/time/test/java/time/format/TestDateTimeFormatterBuilderWithLocale.java
+++ b/test/jdk/java/time/test/java/time/format/TestDateTimeFormatterBuilderWithLocale.java
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2012, 2016, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2012, 2018, Oracle and/or its affiliates. All rights reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -64,24 +64,23 @@
  */
 package test.java.time.format;
 
+import java.time.chrono.ChronoLocalDate;
 import java.time.chrono.Chronology;
 import java.time.chrono.IsoChronology;
 import java.time.chrono.JapaneseChronology;
 import java.time.chrono.JapaneseEra;
 import java.time.chrono.MinguoChronology;
 import java.time.chrono.ThaiBuddhistChronology;
-import java.time.chrono.ChronoLocalDate;
 import java.time.format.DateTimeFormatter;
 import java.time.format.DateTimeFormatterBuilder;
 import java.time.format.FormatStyle;
 import java.time.LocalDate;
+import java.time.temporal.ChronoField;
 import java.time.temporal.Temporal;
-import java.time.temporal.ChronoField;
-import static java.time.temporal.ChronoUnit.YEARS;
 
+import java.util.HashMap;
 import java.util.Locale;
 import java.util.Map;
-import java.util.HashMap;
 
 import static org.testng.Assert.assertEquals;
 
@@ -122,23 +121,21 @@
     }
 
     //-----------------------------------------------------------------------
-    @DataProvider(name="mappedPatterns")
-    Object[][] localizedMappedPatterns() {
+    @DataProvider(name="mapTextLookup")
+    Object[][] data_mapTextLookup() {
         return new Object[][] {
             {IsoChronology.INSTANCE.date(1,1,1), Locale.ENGLISH},
-            {JapaneseChronology.INSTANCE.date(JapaneseEra.HEISEI,
-                                              1,1,8), Locale.ENGLISH},
+            {JapaneseChronology.INSTANCE.date(JapaneseEra.HEISEI, 1, 1, 8), Locale.ENGLISH},
             {MinguoChronology.INSTANCE.date(1,1,1), Locale.ENGLISH},
             {ThaiBuddhistChronology.INSTANCE.date(1,1,1), Locale.ENGLISH},
         };
     }
 
-    @Test(dataProvider="mappedPatterns")
-    public void test_getLocalizedMappedPattern(ChronoLocalDate date, Locale locale) {
+    @Test(dataProvider="mapTextLookup")
+    public void test_appendText_mapTextLookup(ChronoLocalDate date, Locale locale) {
         final String new1st = "1st";
         Map<Long, String> yearMap = new HashMap<>();
         yearMap.put(1L, new1st);
-        DateTimeFormatterBuilder builder = new DateTimeFormatterBuilder();
         builder.appendText(ChronoField.YEAR_OF_ERA, yearMap);
 
         String actual = date.format(builder.toFormatter(locale));

From dipak.kumar at oracle.com  Mon Jun 18 07:29:24 2018
From: dipak.kumar at oracle.com (Dipak Kumar)
Date: Mon, 18 Jun 2018 00:29:24 -0700 (PDT)
Subject: <i18n dev> [11] Review Request: 8202696 glyphs in textfield
 only shown when thai baht-character is added
In-Reply-To: <96579ce3-b499-15bf-1787-97f33113f23d@oracle.com>
References: <17242fed-e6e7-4238-9856-229799ddce1e@default>
 <6cd561e0-fd18-b3ba-7934-57e4cba61441@oracle.com>
 <040f59ee-9c9f-58fb-3b6d-5b2aad3181bf@oracle.com>
 <ce47c811-8fe8-4bcf-923e-c0172992cf5e@default>
 <96579ce3-b499-15bf-1787-97f33113f23d@oracle.com>
Message-ID: <1369e2e7-352a-4f6c-9225-d95b5c6e0e6f@default>

Hi Phil,

I am able to make the test automated after incorporating your suggestion to limit the test case to logical fonts.
I observed that "canDisplayUpTo()" which internally uses "canDisplay()" does return expected values for logical fonts.

Thanks for your guidance.

Please find the updated webrev at http://cr.openjdk.java.net/~dkumar/8202696/webrev.02/ .
Request you to review it again and let me know your comments.

Thanks,
Dipak

-----Original Message-----
From: Phil Race 
Sent: 16 June 2018 00:11
To: Dipak Kumar <dipak.kumar at oracle.com>; 2d-dev at openjdk.java.net; i18n-dev at openjdk.java.net; Naoto Sato <naoto.sato at oracle.com>
Subject: Re: [11] Review Request: 8202696 glyphs in textfield only shown when thai baht-character is added

The exclusion ranges only apply to the logical fonts, so the iteration you are doing looking for any font is now not testing the case you are trying to fix, except by chance. You will need to limit the iteration to the logical fonts.

I don't know why canDisplay(..) did not do what I would expect .. 
particularly
since canDisplayUpTo should be using the same information.

-phil.

On 06/14/2018 12:07 AM, Dipak Kumar wrote:
> Hi Phil,
>
> Thanks for reviewing the patch and providing useful information.
> Regarding your suggestion of using "canDisplay()" in test, I tried using this function to make the test headless.
> But this function is returning true even without proposed fix in fontconfig.properties file. Font exclusion is not coming into picture in this function call.
>
> In the previously written test case, I have added a check for font support (whether characters can be displayed or not using function "canDisplayUpTo()").
> Please find the updated webrev at http://cr.openjdk.java.net/~dkumar/8202696/webrev.01/ .
>
> Request you to have a look into this again and let me know your inputs.
>
> Many thanks,
> Dipak
>
> -----Original Message-----
> From: Phil Race
> Sent: 13 June 2018 03:26
> To: Dipak Kumar <dipak.kumar at oracle.com>; 2d-dev at openjdk.java.net; 
> i18n-dev at openjdk.java.net; Naoto Sato <naoto.sato at oracle.com>
> Subject: Re: [11] Review Request: 8202696 glyphs in textfield only 
> shown when thai baht-character is added
>
> BTW I think the synopsis really needs updating !
>
> Once you know what is going on, continuing to title it after the random empirical observation of the reporter is not necessary. I've changed it to :
>
> "Remove exclusion range for phonetic chars in windows fontconfig.properties"
>
> Please use that in the commit - when you get to it.
>
> -phil.
>
> On 06/12/2018 01:46 PM, Phil Race wrote:
>> I can only guess why this range was excluded.
>> My guess is that it was something to do with an attempt at allowing 
>> as many of these glyphs as possible to come from (for example) a 
>> Chinese font in a chinese locale even though we always put the latin 
>> font first ..
>>
>> The interesting reason why adding a Thai Baht magically makes them 
>> appears is Thai forces TextLayout .. and it (apparently) bypasses the 
>> exclusion range.
>> I suspect this is because layout needs to operate on physical fonts 
>> so gets the list of physical fonts and operates on these explicitly 
>> bypassing CompositeFont which is where this support exists.
>> You can prove that just by using one of these phonetic chars in 
>> Font2DTest without adding Thai or anything else and switching to 
>> TextLayout .. lo and behold .. it appears.
>> I wonder how long that has been the case ? Perhaps so long as to be 
>> effectively forever ..
>>
>> That makes a case for getting rid of all these ranges.
>> The use for the ranges is to control what physical font is used for 
>> glyphs in cases where some font that may be "earlier" in the list 
>> supplies glyphs that you'd actually prefer to come from some other 
>> font.
>> That may be useful if the exclusion ranges were able to be applied 
>> depending on your locale, but this alphabetic exclusion is 
>> particularly questionable.
>>
>> So the change is OK, but can't the test be automated .. and headless ?
>> You just need to do something like ask if the font "canDisplay()"
>> these code points.
>> However the test is fragile in the sense that it assumes that logical 
>> fonts on Windows are capable of supporting them.
>>
>> -phil
>>
>>
>> On 06/04/2018 11:32 PM, Dipak Kumar wrote:
>>> Hi,
>>>
>>> Please review below fix :
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8202696
>>> Webrev: http://cr.openjdk.java.net/~dkumar/8202696/webrev.00/
>>>
>>> Characters which are not getting displayed actually belong to 
>>> Phonetic Extensions 
>>> (https://en.wikipedia.org/wiki/Phonetic_Extensions ).
>>> These characters are not getting rendered properly because they are 
>>> in exclusion range mentioned in the windows.fontconfig.properties file.
>>> In the above fix, font exclusion ranges have been adjusted so that 
>>> these characters do not fall within these ranges
>>>
>>> Font related Jtreg tests and Mach5 client tests are fine.
>>>
>>> Thanks,
>>> Dipak


From takiguc at linux.vnet.ibm.com  Mon Jun 18 17:15:53 2018
From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi)
Date: Tue, 19 Jun 2018 02:15:53 +0900
Subject: <i18n dev> Proposal: Unix/X11 setCompositionEnableNative issue
Message-ID: <9ad6f2166ea8eabcf7391feccf9d8915@linux.vnet.ibm.com>

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 takiguc at linux.vnet.ibm.com  Tue Jun 19 11:50:27 2018
From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi)
Date: Tue, 19 Jun 2018 20:50:27 +0900
Subject: <i18n dev> Proposal: Input Method switch popup menu patch
Message-ID: <591b52020b980e5405823e3e9862e891@linux.vnet.ibm.com>

Hello,
IBM would like to contribute Input Method (IM) switch popup menu patch 
to OpenJDK project.

Issue:
Please try following steps to recreate the issue
Prerequisite:
Download CityIM.jar [1] and InputMethodHotKey.jar [2]
Run InputMethodHotKey.jar to set IM hotkey, like
$ java -jar InputMethodHotKey.jar
(Hotkey, like Shift+F4)

Testcase is as follows:
======
import java.awt.*;
import java.awt.event.*;
import javax.swing.*;

public class IMFTestB {
   IMFTestB(Component comp, int width, int height, int x, int y) {
     Frame f = comp instanceof JComponent ? new JFrame() : new Frame();
     f.setTitle(comp.getClass().getSimpleName());
     f.add(comp);
     f.setSize(width, height);
     f.setLocation(x, y);
     f.addWindowListener(new WindowAdapter() {
       public void windowClosing(WindowEvent we) {
         System.exit(0);
       }
     });
     f.setVisible(true);
   }
   public static void main(String[] args) {
     new IMFTestB(new JTextArea(), 300, 200, 0, 0);
     new IMFTestB(new JButton("JButton"), 300, 200, 300, 0);
     new IMFTestB(new TextArea(), 300, 200, 0, 200);
     Canvas canvas = new Canvas();
     canvas.addKeyListener(new KeyAdapter() { });
     new IMFTestB(canvas, 300, 200, 300, 200);
   }
}
======

1. Compile and run IMFTestB Jwith CityIM.jar
$ java -cp .:CityIM.jar IMFTestB
2. Click JTextArea window
3. Press Shift+F4 key to display IM Switch popup menu is displayed
4. Item can be changed by up and down arrow key
5. Press Shift+F4 key again, then arrow key does not wok
6. Try same thing on JButton window
7. It's OK for TextArea window and Canvas window.

Reason:
2nd IM popup menu is displayed by 4th step

I'd like contribute following 2 files:
M 
src/java.desktop/share/classes/sun/awt/im/ExecutableInputMethodManager.java
M src/java.desktop/share/classes/sun/awt/im/InputMethodPopupMenu.java
http://cr.openjdk.java.net/~aleonard/im_popup/webrev.00/

I appreciate any feedback please, and how I would go about obtaining a 
sponsor and contributor?

[1] 
https://docs.oracle.com/javase/1.5.0/docs/guide/imf/spi-tutorial.html#Sample%20Code
[2] http://javadesktop.org/articles/InputMethod/index.html

Thanks,
Ichiroh Takiguchi
IBM Japan, Ltd.


From philip.race at oracle.com  Tue Jun 19 18:32:42 2018
From: philip.race at oracle.com (Phil Race)
Date: Tue, 19 Jun 2018 11:32:42 -0700
Subject: <i18n dev> <AWT Dev> Proposal:X11 default visual support for IM
 status window on VNC
In-Reply-To: <a8c838bb-3922-a5e7-68fd-ecd81de1722c@oracle.com>
References: <46b05293c2bab165a413ac1ac18e0703@linux.vnet.ibm.com>
 <4cb2abda-706f-8b1a-320c-64285ebfafae@oracle.com>
 <34954ce768b5b3254a3122cb8c0ed268@linux.vnet.ibm.com>
 <a8c838bb-3922-a5e7-68fd-ecd81de1722c@oracle.com>
Message-ID: <2f1d4840-7140-861e-cdac-5bfac039a5c4@oracle.com>

Where's the bug ID ?

The review should have a bug ID in the subject line so we can all find 
it later !

Is this changing the default visual  for all WIndows, not just the IM 
status window?
I think we need to understand the implications before this can be accepted.

Similarly for the fontset change .. this might change what others get.
The fontset spec. there seems very loose to me ..

I think I18N-DEV should be asked about this too.

-phil.

On 06/19/2018 11:07 AM, Sergey Bylokhov wrote:
> Looks fine, if there are no other comments I'll push the fix using the 
> new bugid.
>
> On 06/06/2018 17:54, Ichiroh Takiguchi wrote:
>> Hello Sergey.
>> Thank you for your review.
>>
>> Could you review following patch ?
>> http://cr.openjdk.java.net/~aleonard/defvis/webrev.01/
>>
>> Thanks,
>> Ichiroh Takiguchi
>> IBM Japan, Ltd.
>>
>> On 2018-06-06 07:15, Sergey Bylokhov wrote:
>>> Hi, Ichiroh.
>>> The approach looks fine, but maybe it is possible to decrees code
>>> duplication in findWithTemplate(). After the fix it will have two
>>> similar loops.
>>>
>>> On 24/05/2018 22:24, Ichiroh Takiguchi wrote:
>>>> Hello,
>>>> IBM would like to contribute X11 default visual support for IM 
>>>> status window patch to OpenJDK project.
>>>>
>>>> Issue:
>>>> Java's Native IM status window is not displayed even if it's there.
>>>> Because of this issue, user cannot get proper visual feedback 
>>>> during key input operation.
>>>> We found this issue on Tiger VNC.
>>>>
>>>> Reason:
>>>> Java may pick up unexpected visual for Java's Native IM status 
>>>> window when  Xserver supports multiple visual.
>>>>
>>>> Workaround:
>>>> X11 default visual can be changed by FORCEDEFVIS environment 
>>>> variable, but it's not easy to find out default visual id.
>>>>
>>>> I'd like contribute following 2 files:
>>>> M src/java.desktop/unix/native/libawt_xawt/awt/awt_GraphicsEnv.c
>>>> (Change X11 visual setting)
>>>> M src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c
>>>> (Support 13 point X11 misc fonts (like k14 font for Japanese), 
>>>> since the fonts may defined for unscaled fonts.)
>>>>
>>>> webrev files are in
>>>> http://cr.openjdk.java.net/~aleonard/defvis/
>>>>
>>>> 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  Tue Jun 19 19:54:37 2018
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 19 Jun 2018 12:54:37 -0700
Subject: <i18n dev> <AWT Dev> Proposal:X11 default visual support for IM
 status window on VNC
In-Reply-To: <2f1d4840-7140-861e-cdac-5bfac039a5c4@oracle.com>
References: <46b05293c2bab165a413ac1ac18e0703@linux.vnet.ibm.com>
 <4cb2abda-706f-8b1a-320c-64285ebfafae@oracle.com>
 <34954ce768b5b3254a3122cb8c0ed268@linux.vnet.ibm.com>
 <a8c838bb-3922-a5e7-68fd-ecd81de1722c@oracle.com>
 <2f1d4840-7140-861e-cdac-5bfac039a5c4@oracle.com>
Message-ID: <068fccf8-05a9-0e32-0540-551ade446f96@oracle.com>

Looks OK wrt awt_InputMethod.c change.

Naoto

On 6/19/18 11:32 AM, Phil Race wrote:
> Where's the bug ID ?
> 
> The review should have a bug ID in the subject line so we can all find 
> it later !
> 
> Is this changing the default visual? for all WIndows, not just the IM 
> status window?
> I think we need to understand the implications before this can be accepted.
> 
> Similarly for the fontset change .. this might change what others get.
> The fontset spec. there seems very loose to me ..
> 
> I think I18N-DEV should be asked about this too.
> 
> -phil.
> 
> On 06/19/2018 11:07 AM, Sergey Bylokhov wrote:
>> Looks fine, if there are no other comments I'll push the fix using the 
>> new bugid.
>>
>> On 06/06/2018 17:54, Ichiroh Takiguchi wrote:
>>> Hello Sergey.
>>> Thank you for your review.
>>>
>>> Could you review following patch ?
>>> http://cr.openjdk.java.net/~aleonard/defvis/webrev.01/
>>>
>>> Thanks,
>>> Ichiroh Takiguchi
>>> IBM Japan, Ltd.
>>>
>>> On 2018-06-06 07:15, Sergey Bylokhov wrote:
>>>> Hi, Ichiroh.
>>>> The approach looks fine, but maybe it is possible to decrees code
>>>> duplication in findWithTemplate(). After the fix it will have two
>>>> similar loops.
>>>>
>>>> On 24/05/2018 22:24, Ichiroh Takiguchi wrote:
>>>>> Hello,
>>>>> IBM would like to contribute X11 default visual support for IM 
>>>>> status window patch to OpenJDK project.
>>>>>
>>>>> Issue:
>>>>> Java's Native IM status window is not displayed even if it's there.
>>>>> Because of this issue, user cannot get proper visual feedback 
>>>>> during key input operation.
>>>>> We found this issue on Tiger VNC.
>>>>>
>>>>> Reason:
>>>>> Java may pick up unexpected visual for Java's Native IM status 
>>>>> window when? Xserver supports multiple visual.
>>>>>
>>>>> Workaround:
>>>>> X11 default visual can be changed by FORCEDEFVIS environment 
>>>>> variable, but it's not easy to find out default visual id.
>>>>>
>>>>> I'd like contribute following 2 files:
>>>>> M src/java.desktop/unix/native/libawt_xawt/awt/awt_GraphicsEnv.c
>>>>> (Change X11 visual setting)
>>>>> M src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c
>>>>> (Support 13 point X11 misc fonts (like k14 font for Japanese), 
>>>>> since the fonts may defined for unscaled fonts.)
>>>>>
>>>>> webrev files are in
>>>>> http://cr.openjdk.java.net/~aleonard/defvis/
>>>>>
>>>>> 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  Tue Jun 19 19:59:59 2018
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 19 Jun 2018 12:59:59 -0700
Subject: <i18n dev> <AWT Dev> Proposal:X11 default visual support for IM
 status window on VNC
In-Reply-To: <068fccf8-05a9-0e32-0540-551ade446f96@oracle.com>
References: <46b05293c2bab165a413ac1ac18e0703@linux.vnet.ibm.com>
 <4cb2abda-706f-8b1a-320c-64285ebfafae@oracle.com>
 <34954ce768b5b3254a3122cb8c0ed268@linux.vnet.ibm.com>
 <a8c838bb-3922-a5e7-68fd-ecd81de1722c@oracle.com>
 <2f1d4840-7140-861e-cdac-5bfac039a5c4@oracle.com>
 <068fccf8-05a9-0e32-0540-551ade446f96@oracle.com>
Message-ID: <e29c2dbe-b684-a46a-3d05-d35c1ee42fd0@oracle.com>

Please change the comment in line 680, which should also mention 13 
point font.

Naoto

On 6/19/18 12:54 PM, Naoto Sato wrote:
> Looks OK wrt awt_InputMethod.c change.
> 
> Naoto
> 
> On 6/19/18 11:32 AM, Phil Race wrote:
>> Where's the bug ID ?
>>
>> The review should have a bug ID in the subject line so we can all find 
>> it later !
>>
>> Is this changing the default visual? for all WIndows, not just the IM 
>> status window?
>> I think we need to understand the implications before this can be 
>> accepted.
>>
>> Similarly for the fontset change .. this might change what others get.
>> The fontset spec. there seems very loose to me ..
>>
>> I think I18N-DEV should be asked about this too.
>>
>> -phil.
>>
>> On 06/19/2018 11:07 AM, Sergey Bylokhov wrote:
>>> Looks fine, if there are no other comments I'll push the fix using 
>>> the new bugid.
>>>
>>> On 06/06/2018 17:54, Ichiroh Takiguchi wrote:
>>>> Hello Sergey.
>>>> Thank you for your review.
>>>>
>>>> Could you review following patch ?
>>>> http://cr.openjdk.java.net/~aleonard/defvis/webrev.01/
>>>>
>>>> Thanks,
>>>> Ichiroh Takiguchi
>>>> IBM Japan, Ltd.
>>>>
>>>> On 2018-06-06 07:15, Sergey Bylokhov wrote:
>>>>> Hi, Ichiroh.
>>>>> The approach looks fine, but maybe it is possible to decrees code
>>>>> duplication in findWithTemplate(). After the fix it will have two
>>>>> similar loops.
>>>>>
>>>>> On 24/05/2018 22:24, Ichiroh Takiguchi wrote:
>>>>>> Hello,
>>>>>> IBM would like to contribute X11 default visual support for IM 
>>>>>> status window patch to OpenJDK project.
>>>>>>
>>>>>> Issue:
>>>>>> Java's Native IM status window is not displayed even if it's there.
>>>>>> Because of this issue, user cannot get proper visual feedback 
>>>>>> during key input operation.
>>>>>> We found this issue on Tiger VNC.
>>>>>>
>>>>>> Reason:
>>>>>> Java may pick up unexpected visual for Java's Native IM status 
>>>>>> window when? Xserver supports multiple visual.
>>>>>>
>>>>>> Workaround:
>>>>>> X11 default visual can be changed by FORCEDEFVIS environment 
>>>>>> variable, but it's not easy to find out default visual id.
>>>>>>
>>>>>> I'd like contribute following 2 files:
>>>>>> M src/java.desktop/unix/native/libawt_xawt/awt/awt_GraphicsEnv.c
>>>>>> (Change X11 visual setting)
>>>>>> M src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c
>>>>>> (Support 13 point X11 misc fonts (like k14 font for Japanese), 
>>>>>> since the fonts may defined for unscaled fonts.)
>>>>>>
>>>>>> webrev files are in
>>>>>> http://cr.openjdk.java.net/~aleonard/defvis/
>>>>>>
>>>>>> I appreciate any feedback please, and how I would go about 
>>>>>> obtaining a sponsor and contributor?
>>>>>>
>>>>>> Thanks,
>>>>>> Ichiroh Takiguchi
>>>>>> IBM Japan, Ltd.
>>>>>>
>>>>
>>>
>>>
>>

From nishit.jain at oracle.com  Wed Jun 20 10:32:15 2018
From: nishit.jain at oracle.com (Nishit Jain)
Date: Wed, 20 Jun 2018 16:02:15 +0530
Subject: <i18n dev> RFR JDK-8204938: Add a test case to automatically check
 the updated LSR data
Message-ID: <342415ad-b407-66f9-85a0-3f5aedc6f996@oracle.com>

Hi,

Please review the fix for JDK-8204938

Bug: https://bugs.openjdk.java.net/browse/JDK-8204938
Webrev: http://cr.openjdk.java.net/~nishjain/8204938/webrev.02/

Fix: Added a test case to cross check the LSR data generated for the JDK 
APIs. So, for each lsr data update, the test case need not be updated, 
it automatically cross checks the updated lsr data.

Regards,
Nishit Jain

From takiguc at linux.vnet.ibm.com  Wed Jun 20 11:23:19 2018
From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi)
Date: Wed, 20 Jun 2018 20:23:19 +0900
Subject: <i18n dev> <AWT Dev> Proposal:X11 default visual support for IM
 status window on VNC
In-Reply-To: <e29c2dbe-b684-a46a-3d05-d35c1ee42fd0@oracle.com>
References: <46b05293c2bab165a413ac1ac18e0703@linux.vnet.ibm.com>
 <4cb2abda-706f-8b1a-320c-64285ebfafae@oracle.com>
 <34954ce768b5b3254a3122cb8c0ed268@linux.vnet.ibm.com>
 <a8c838bb-3922-a5e7-68fd-ecd81de1722c@oracle.com>
 <2f1d4840-7140-861e-cdac-5bfac039a5c4@oracle.com>
 <068fccf8-05a9-0e32-0540-551ade446f96@oracle.com>
 <e29c2dbe-b684-a46a-3d05-d35c1ee42fd0@oracle.com>
Message-ID: <ce63b81cd31c5a82af1b543075ef537d@linux.vnet.ibm.com>

Hello.

New fixed code is in:
http://cr.openjdk.java.net/~aleonard/defvis/webrev.02/

Could you check fixed files again ?

I only updated following part between webrev.01 and webrev.02
======
diff -r 70a582d110a1 -r 6f04164a9d62 
src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c
--- a/src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c    
Wed Jun 06 21:03:25 2018 +0900
+++ b/src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c    
Wed Jun 20 16:54:24 2018 +0900
@@ -677,7 +677,7 @@
          return NULL;
      }
      statusWindow->w = status;
-    //12-point font
+    //12, 13-point fonts
      statusWindow->fontset = XCreateFontSet(dpy,
                                             
"-*-*-medium-r-normal-*-*-120-*-*-*-*," \
                                             
"-*-*-medium-r-normal-*-*-130-*-*-*-*",
======


Please create bugid and handle it.

Thanks,
Ichiroh Takiguchi
IBM Japan, Ltd.

On 2018-06-20 04:59, Naoto Sato wrote:
> Please change the comment in line 680, which should also mention 13 
> point font.
> 
> Naoto
> 
> On 6/19/18 12:54 PM, Naoto Sato wrote:
>> Looks OK wrt awt_InputMethod.c change.
>> 
>> Naoto
>> 
>> On 6/19/18 11:32 AM, Phil Race wrote:
>>> Where's the bug ID ?
>>> 
>>> The review should have a bug ID in the subject line so we can all 
>>> find it later !
>>> 
>>> Is this changing the default visual? for all WIndows, not just the 
>>> IM status window?
>>> I think we need to understand the implications before this can be 
>>> accepted.
>>> 
>>> Similarly for the fontset change .. this might change what others 
>>> get.
>>> The fontset spec. there seems very loose to me ..
>>> 
>>> I think I18N-DEV should be asked about this too.
>>> 
>>> -phil.
>>> 
>>> On 06/19/2018 11:07 AM, Sergey Bylokhov wrote:
>>>> Looks fine, if there are no other comments I'll push the fix using 
>>>> the new bugid.
>>>> 
>>>> On 06/06/2018 17:54, Ichiroh Takiguchi wrote:
>>>>> Hello Sergey.
>>>>> Thank you for your review.
>>>>> 
>>>>> Could you review following patch ?
>>>>> http://cr.openjdk.java.net/~aleonard/defvis/webrev.01/
>>>>> 
>>>>> Thanks,
>>>>> Ichiroh Takiguchi
>>>>> IBM Japan, Ltd.
>>>>> 
>>>>> On 2018-06-06 07:15, Sergey Bylokhov wrote:
>>>>>> Hi, Ichiroh.
>>>>>> The approach looks fine, but maybe it is possible to decrees code
>>>>>> duplication in findWithTemplate(). After the fix it will have two
>>>>>> similar loops.
>>>>>> 
>>>>>> On 24/05/2018 22:24, Ichiroh Takiguchi wrote:
>>>>>>> Hello,
>>>>>>> IBM would like to contribute X11 default visual support for IM 
>>>>>>> status window patch to OpenJDK project.
>>>>>>> 
>>>>>>> Issue:
>>>>>>> Java's Native IM status window is not displayed even if it's 
>>>>>>> there.
>>>>>>> Because of this issue, user cannot get proper visual feedback 
>>>>>>> during key input operation.
>>>>>>> We found this issue on Tiger VNC.
>>>>>>> 
>>>>>>> Reason:
>>>>>>> Java may pick up unexpected visual for Java's Native IM status 
>>>>>>> window when? Xserver supports multiple visual.
>>>>>>> 
>>>>>>> Workaround:
>>>>>>> X11 default visual can be changed by FORCEDEFVIS environment 
>>>>>>> variable, but it's not easy to find out default visual id.
>>>>>>> 
>>>>>>> I'd like contribute following 2 files:
>>>>>>> M src/java.desktop/unix/native/libawt_xawt/awt/awt_GraphicsEnv.c
>>>>>>> (Change X11 visual setting)
>>>>>>> M src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c
>>>>>>> (Support 13 point X11 misc fonts (like k14 font for Japanese), 
>>>>>>> since the fonts may defined for unscaled fonts.)
>>>>>>> 
>>>>>>> webrev files are in
>>>>>>> http://cr.openjdk.java.net/~aleonard/defvis/
>>>>>>> 
>>>>>>> I appreciate any feedback please, and how I would go about 
>>>>>>> obtaining a sponsor and contributor?
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> Ichiroh Takiguchi
>>>>>>> IBM Japan, Ltd.
>>>>>>> 
>>>>> 
>>>> 
>>>> 
>>> 


From philip.race at oracle.com  Wed Jun 20 14:14:56 2018
From: philip.race at oracle.com (Philip Race)
Date: Wed, 20 Jun 2018 07:14:56 -0700
Subject: <i18n dev> <AWT Dev> Proposal:X11 default visual support for IM
 status window on VNC
In-Reply-To: <ce63b81cd31c5a82af1b543075ef537d@linux.vnet.ibm.com>
References: <46b05293c2bab165a413ac1ac18e0703@linux.vnet.ibm.com>
 <4cb2abda-706f-8b1a-320c-64285ebfafae@oracle.com>
 <34954ce768b5b3254a3122cb8c0ed268@linux.vnet.ibm.com>
 <a8c838bb-3922-a5e7-68fd-ecd81de1722c@oracle.com>
 <2f1d4840-7140-861e-cdac-5bfac039a5c4@oracle.com>
 <068fccf8-05a9-0e32-0540-551ade446f96@oracle.com>
 <e29c2dbe-b684-a46a-3d05-d35c1ee42fd0@oracle.com>
 <ce63b81cd31c5a82af1b543075ef537d@linux.vnet.ibm.com>
Message-ID: <5B2A6160.5000107@oracle.com>

My question has not been answered. I don't think this is ready to go in.

-phil.

On 6/20/18, 4:23 AM, Ichiroh Takiguchi wrote:
> Hello.
>
> New fixed code is in:
> http://cr.openjdk.java.net/~aleonard/defvis/webrev.02/
>
> Could you check fixed files again ?
>
> I only updated following part between webrev.01 and webrev.02
> ======
> diff -r 70a582d110a1 -r 6f04164a9d62 
> src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c
> --- 
> a/src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c    
> Wed Jun 06 21:03:25 2018 +0900
> +++ 
> b/src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c    
> Wed Jun 20 16:54:24 2018 +0900
> @@ -677,7 +677,7 @@
>          return NULL;
>      }
>      statusWindow->w = status;
> -    //12-point font
> +    //12, 13-point fonts
>      statusWindow->fontset = XCreateFontSet(dpy,
>                                             
> "-*-*-medium-r-normal-*-*-120-*-*-*-*," \
>                                             
> "-*-*-medium-r-normal-*-*-130-*-*-*-*",
> ======
>
>
> Please create bugid and handle it.
>
> Thanks,
> Ichiroh Takiguchi
> IBM Japan, Ltd.
>
> On 2018-06-20 04:59, Naoto Sato wrote:
>> Please change the comment in line 680, which should also mention 13 
>> point font.
>>
>> Naoto
>>
>> On 6/19/18 12:54 PM, Naoto Sato wrote:
>>> Looks OK wrt awt_InputMethod.c change.
>>>
>>> Naoto
>>>
>>> On 6/19/18 11:32 AM, Phil Race wrote:
>>>> Where's the bug ID ?
>>>>
>>>> The review should have a bug ID in the subject line so we can all 
>>>> find it later !
>>>>
>>>> Is this changing the default visual  for all WIndows, not just the 
>>>> IM status window?
>>>> I think we need to understand the implications before this can be 
>>>> accepted.
>>>>
>>>> Similarly for the fontset change .. this might change what others get.
>>>> The fontset spec. there seems very loose to me ..
>>>>
>>>> I think I18N-DEV should be asked about this too.
>>>>
>>>> -phil.
>>>>
>>>> On 06/19/2018 11:07 AM, Sergey Bylokhov wrote:
>>>>> Looks fine, if there are no other comments I'll push the fix using 
>>>>> the new bugid.
>>>>>
>>>>> On 06/06/2018 17:54, Ichiroh Takiguchi wrote:
>>>>>> Hello Sergey.
>>>>>> Thank you for your review.
>>>>>>
>>>>>> Could you review following patch ?
>>>>>> http://cr.openjdk.java.net/~aleonard/defvis/webrev.01/
>>>>>>
>>>>>> Thanks,
>>>>>> Ichiroh Takiguchi
>>>>>> IBM Japan, Ltd.
>>>>>>
>>>>>> On 2018-06-06 07:15, Sergey Bylokhov wrote:
>>>>>>> Hi, Ichiroh.
>>>>>>> The approach looks fine, but maybe it is possible to decrees code
>>>>>>> duplication in findWithTemplate(). After the fix it will have two
>>>>>>> similar loops.
>>>>>>>
>>>>>>> On 24/05/2018 22:24, Ichiroh Takiguchi wrote:
>>>>>>>> Hello,
>>>>>>>> IBM would like to contribute X11 default visual support for IM 
>>>>>>>> status window patch to OpenJDK project.
>>>>>>>>
>>>>>>>> Issue:
>>>>>>>> Java's Native IM status window is not displayed even if it's 
>>>>>>>> there.
>>>>>>>> Because of this issue, user cannot get proper visual feedback 
>>>>>>>> during key input operation.
>>>>>>>> We found this issue on Tiger VNC.
>>>>>>>>
>>>>>>>> Reason:
>>>>>>>> Java may pick up unexpected visual for Java's Native IM status 
>>>>>>>> window when  Xserver supports multiple visual.
>>>>>>>>
>>>>>>>> Workaround:
>>>>>>>> X11 default visual can be changed by FORCEDEFVIS environment 
>>>>>>>> variable, but it's not easy to find out default visual id.
>>>>>>>>
>>>>>>>> I'd like contribute following 2 files:
>>>>>>>> M src/java.desktop/unix/native/libawt_xawt/awt/awt_GraphicsEnv.c
>>>>>>>> (Change X11 visual setting)
>>>>>>>> M src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c
>>>>>>>> (Support 13 point X11 misc fonts (like k14 font for Japanese), 
>>>>>>>> since the fonts may defined for unscaled fonts.)
>>>>>>>>
>>>>>>>> webrev files are in
>>>>>>>> http://cr.openjdk.java.net/~aleonard/defvis/
>>>>>>>>
>>>>>>>> I appreciate any feedback please, and how I would go about 
>>>>>>>> obtaining a sponsor and contributor?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Ichiroh Takiguchi
>>>>>>>> IBM Japan, Ltd.
>>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>

From philip.race at oracle.com  Wed Jun 20 17:28:21 2018
From: philip.race at oracle.com (Phil Race)
Date: Wed, 20 Jun 2018 10:28:21 -0700
Subject: <i18n dev> [11] Review Request: 8202696 glyphs in textfield
 only shown when thai baht-character is added
In-Reply-To: <1369e2e7-352a-4f6c-9225-d95b5c6e0e6f@default>
References: <17242fed-e6e7-4238-9856-229799ddce1e@default>
 <6cd561e0-fd18-b3ba-7934-57e4cba61441@oracle.com>
 <040f59ee-9c9f-58fb-3b6d-5b2aad3181bf@oracle.com>
 <ce47c811-8fe8-4bcf-923e-c0172992cf5e@default>
 <96579ce3-b499-15bf-1787-97f33113f23d@oracle.com>
 <1369e2e7-352a-4f6c-9225-d95b5c6e0e6f@default>
Message-ID: <628258b1-f005-1f9a-0f01-561e6722e3ac@oracle.com>

+1 (approved).

-phil.

On 06/18/2018 12:29 AM, Dipak Kumar wrote:
> Hi Phil,
>
> I am able to make the test automated after incorporating your suggestion to limit the test case to logical fonts.
> I observed that "canDisplayUpTo()" which internally uses "canDisplay()" does return expected values for logical fonts.
>
> Thanks for your guidance.
>
> Please find the updated webrev at http://cr.openjdk.java.net/~dkumar/8202696/webrev.02/ .
> Request you to review it again and let me know your comments.
>
> Thanks,
> Dipak
>
> -----Original Message-----
> From: Phil Race
> Sent: 16 June 2018 00:11
> To: Dipak Kumar <dipak.kumar at oracle.com>; 2d-dev at openjdk.java.net; i18n-dev at openjdk.java.net; Naoto Sato <naoto.sato at oracle.com>
> Subject: Re: [11] Review Request: 8202696 glyphs in textfield only shown when thai baht-character is added
>
> The exclusion ranges only apply to the logical fonts, so the iteration you are doing looking for any font is now not testing the case you are trying to fix, except by chance. You will need to limit the iteration to the logical fonts.
>
> I don't know why canDisplay(..) did not do what I would expect ..
> particularly
> since canDisplayUpTo should be using the same information.
>
> -phil.
>
> On 06/14/2018 12:07 AM, Dipak Kumar wrote:
>> Hi Phil,
>>
>> Thanks for reviewing the patch and providing useful information.
>> Regarding your suggestion of using "canDisplay()" in test, I tried using this function to make the test headless.
>> But this function is returning true even without proposed fix in fontconfig.properties file. Font exclusion is not coming into picture in this function call.
>>
>> In the previously written test case, I have added a check for font support (whether characters can be displayed or not using function "canDisplayUpTo()").
>> Please find the updated webrev at http://cr.openjdk.java.net/~dkumar/8202696/webrev.01/ .
>>
>> Request you to have a look into this again and let me know your inputs.
>>
>> Many thanks,
>> Dipak
>>
>> -----Original Message-----
>> From: Phil Race
>> Sent: 13 June 2018 03:26
>> To: Dipak Kumar <dipak.kumar at oracle.com>; 2d-dev at openjdk.java.net;
>> i18n-dev at openjdk.java.net; Naoto Sato <naoto.sato at oracle.com>
>> Subject: Re: [11] Review Request: 8202696 glyphs in textfield only
>> shown when thai baht-character is added
>>
>> BTW I think the synopsis really needs updating !
>>
>> Once you know what is going on, continuing to title it after the random empirical observation of the reporter is not necessary. I've changed it to :
>>
>> "Remove exclusion range for phonetic chars in windows fontconfig.properties"
>>
>> Please use that in the commit - when you get to it.
>>
>> -phil.
>>
>> On 06/12/2018 01:46 PM, Phil Race wrote:
>>> I can only guess why this range was excluded.
>>> My guess is that it was something to do with an attempt at allowing
>>> as many of these glyphs as possible to come from (for example) a
>>> Chinese font in a chinese locale even though we always put the latin
>>> font first ..
>>>
>>> The interesting reason why adding a Thai Baht magically makes them
>>> appears is Thai forces TextLayout .. and it (apparently) bypasses the
>>> exclusion range.
>>> I suspect this is because layout needs to operate on physical fonts
>>> so gets the list of physical fonts and operates on these explicitly
>>> bypassing CompositeFont which is where this support exists.
>>> You can prove that just by using one of these phonetic chars in
>>> Font2DTest without adding Thai or anything else and switching to
>>> TextLayout .. lo and behold .. it appears.
>>> I wonder how long that has been the case ? Perhaps so long as to be
>>> effectively forever ..
>>>
>>> That makes a case for getting rid of all these ranges.
>>> The use for the ranges is to control what physical font is used for
>>> glyphs in cases where some font that may be "earlier" in the list
>>> supplies glyphs that you'd actually prefer to come from some other
>>> font.
>>> That may be useful if the exclusion ranges were able to be applied
>>> depending on your locale, but this alphabetic exclusion is
>>> particularly questionable.
>>>
>>> So the change is OK, but can't the test be automated .. and headless ?
>>> You just need to do something like ask if the font "canDisplay()"
>>> these code points.
>>> However the test is fragile in the sense that it assumes that logical
>>> fonts on Windows are capable of supporting them.
>>>
>>> -phil
>>>
>>>
>>> On 06/04/2018 11:32 PM, Dipak Kumar wrote:
>>>> Hi,
>>>>
>>>> Please review below fix :
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8202696
>>>> Webrev: http://cr.openjdk.java.net/~dkumar/8202696/webrev.00/
>>>>
>>>> Characters which are not getting displayed actually belong to
>>>> Phonetic Extensions
>>>> (https://en.wikipedia.org/wiki/Phonetic_Extensions ).
>>>> These characters are not getting rendered properly because they are
>>>> in exclusion range mentioned in the windows.fontconfig.properties file.
>>>> In the above fix, font exclusion ranges have been adjusted so that
>>>> these characters do not fall within these ranges
>>>>
>>>> Font related Jtreg tests and Mach5 client tests are fine.
>>>>
>>>> Thanks,
>>>> Dipak


From naoto.sato at oracle.com  Wed Jun 20 18:27:30 2018
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Wed, 20 Jun 2018 11:27:30 -0700
Subject: <i18n dev> RFR JDK-8204938: Add a test case to automatically
 check the updated LSR data
In-Reply-To: <342415ad-b407-66f9-85a0-3f5aedc6f996@oracle.com>
References: <342415ad-b407-66f9-85a0-3f5aedc6f996@oracle.com>
Message-ID: <e0e798eb-a946-2f5b-8f3b-d0c2a1f9397e@oracle.com>

Looks good.

Naoto

On 6/20/18 3:32 AM, Nishit Jain wrote:
> Hi,
> 
> Please review the fix for JDK-8204938
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8204938
> Webrev: http://cr.openjdk.java.net/~nishjain/8204938/webrev.02/
> 
> Fix: Added a test case to cross check the LSR data generated for the JDK 
> APIs. So, for each lsr data update, the test case need not be updated, 
> it automatically cross checks the updated lsr data.
> 
> Regards,
> Nishit Jain

From takiguc at linux.vnet.ibm.com  Thu Jun 21 12:58:42 2018
From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi)
Date: Thu, 21 Jun 2018 21:58:42 +0900
Subject: <i18n dev> <AWT Dev> Proposal:X11 default visual support for IM
 status window on VNC
In-Reply-To: <5B2A6160.5000107@oracle.com>
References: <46b05293c2bab165a413ac1ac18e0703@linux.vnet.ibm.com>
 <4cb2abda-706f-8b1a-320c-64285ebfafae@oracle.com>
 <34954ce768b5b3254a3122cb8c0ed268@linux.vnet.ibm.com>
 <a8c838bb-3922-a5e7-68fd-ecd81de1722c@oracle.com>
 <2f1d4840-7140-861e-cdac-5bfac039a5c4@oracle.com>
 <068fccf8-05a9-0e32-0540-551ade446f96@oracle.com>
 <e29c2dbe-b684-a46a-3d05-d35c1ee42fd0@oracle.com>
 <ce63b81cd31c5a82af1b543075ef537d@linux.vnet.ibm.com>
 <5B2A6160.5000107@oracle.com>
Message-ID: <674fa1d548764758a051953ce9a97d95@linux.vnet.ibm.com>

Hello Phil.

I'm sorry, I forgot to put my comment against your question.

> Is this changing the default visual  for all WIndows, not just the IM 
> status window?
> I think we need to understand the implications before this can be 
> accepted.
I put following debug code:
=======
diff -r e1b3def12624 
src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c
--- a/src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c    
Wed Jun 13 06:35:04 2018 +0200
+++ b/src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c    
Thu Jun 21 21:23:11 2018 +0900
@@ -667,6 +667,7 @@
                              InputOutput,
                              adata->awt_visInfo.visual,
                              attribmask, &attrib);
+    fprintf(stderr, "status window id = 0x%X\n", status);
      XSelectInput(dpy, status,
                   ExposureMask | StructureNotifyMask | EnterWindowMask |
                   LeaveWindowMask | VisibilityChangeMask);
@@ -680,6 +681,21 @@
      statusWindow->fontset = XCreateFontSet(dpy,
                                             
"-*-*-medium-r-normal-*-*-120-*-*-*-*",
                                             &mclr, &mccr, &dsr);
+    {
+        int cntFonts;
+        for(cntFonts = 0; cntFonts < mccr; cntFonts++) {
+            fprintf(stderr, "[M][%d] %s\n", cntFonts, mclr[cntFonts]);
+        }
+    }
+    {
+        XFontStruct **font_struct_list;
+        char **font_name_list;
+        int cntFonts;
+        int numFonts = XFontsOfFontSet(statusWindow->fontset, 
&font_struct_list, &font_name_list);
+        for(cntFonts = 0; cntFonts < numFonts; cntFonts++) {
+            fprintf(stderr, "[L][%d] %s\n", cntFonts, 
font_name_list[cntFonts]);
+        }
+    }
      /* In case we didn't find the font set, release the list of missing 
characters */
      if (mccr > 0) {
          XFreeStringList(mclr);
=======

I tested it on RHEL7.
I thought since window id was assigned, but it was gone on current code.
=======
$ java -jar Notepad.jar
status window id = 0x4000055
...
$ xwininfo -id 0x4000055
X Error: 9: Bad Drawable: 0x4000055
   Request Major code: 14
   Request serial number: 3
xwininfo: error: No such window with id 0x4000055.
=======

=======
$ java -jar Notepad.jar
status window id = 0x40000CA
...
$ xwininfo -id 0x40000CA

xwininfo: Window id: 0x40000ca (has no name)

   Absolute upper-left X:  0
   Absolute upper-left Y:  600
   Relative upper-left X:  0
   Relative upper-left Y:  600
   Width: 80
   Height: 22
   Depth: 24
   Visual: 0x21
   Visual Class: TrueColor
   Border width: 0
   Class: InputOutput
   Colormap: 0x20 (installed)
   Bit Gravity State: ForgetGravity
   Window Gravity State: NorthWestGravity
   Backing Store State: NotUseful
   Save Under State: no
   Map State: IsUnMapped
   Override Redirect State: yes
   Corners:  +0+600  -944+600  -944-146  +0-146
   -geometry 80x22+0+600
=======

According to main window: (Left side: without fix, right side: with fix)
=======
xwininfo: Window id: 0x4000009 " (failure   |   xwininfo: Window id: 
0x460007e " (failure

   Absolute upper-left X:  4                       Absolute upper-left X: 
  4
   Absolute upper-left Y:  25                      Absolute upper-left Y: 
  25
   Relative upper-left X:  0                       Relative upper-left X: 
  0
   Relative upper-left Y:  0                       Relative upper-left Y: 
  0
   Width: 492                                      Width: 492
   Height: 571                                     Height: 571
   Depth: 24                                       Depth: 24
   Visual: 0x169                             |     Visual: 0x21
   Visual Class: TrueColor                         Visual Class: 
TrueColor
   Border width: 0                                 Border width: 0
   Class: InputOutput                              Class: InputOutput
   Colormap: 0x4000008 (not installed)       |     Colormap: 0x20 
(installed)
   Bit Gravity State: NorthWestGravity             Bit Gravity State: 
NorthWestGravity
   Window Gravity State: NorthWestGravity          Window Gravity State: 
NorthWestGravity
   Backing Store State: NotUseful                  Backing Store State: 
NotUseful
   Save Under State: no                            Save Under State: no
   Map State: IsViewable                           Map State: IsViewable
   Override Redirect State: no                     Override Redirect 
State: no
   Corners:  +4+25  -528+25  -528-172  +4-1        Corners:  +4+25  
-528+25  -528-172  +4-1
   -geometry 492x571+0+0                           -geometry 492x571+0+0
=======

So main window's visual also changed by this fix.

> Similarly for the fontset change .. this might change what others get.
> The fontset spec. there seems very loose to me ..

Without fix
=======
$ java -jar Notepad.jar
status window id = 0x4000055
[M][0] JISX0208.1983-0
[M][1] GB2312.1980-0
[L][0] -misc-fixed-medium-r-normal--13-120-75-75-c-70-iso8859-1
[L][1] -misc-fixed-medium-r-normal--13-120-75-75-c-70-iso8859-1
[L][2] 
-daewoo-gothic-medium-r-normal--16-120-100-100-c-160-ksc5601.1987-0
[L][3] -sony-fixed-medium-r-normal--16-120-100-100-c-80-jisx0201.1976-0
[L][4] -misc-fixed-medium-r-normal--13-120-75-75-c-70-iso10646-1
=======

With fix
=======
$ java -jar Notepad.jar
status window id = 0x40000CA
[M][0] GB2312.1980-0
[L][0] -misc-fixed-medium-r-normal--13-120-75-75-c-70-iso8859-1
[L][1] -misc-fixed-medium-r-normal--13-120-75-75-c-70-iso8859-1
[L][2] -misc-fixed-medium-r-normal--14-130-75-75-c-140-jisx0208.1983-0
[L][3] 
-daewoo-gothic-medium-r-normal--16-120-100-100-c-160-ksc5601.1987-0
[L][4] -sony-fixed-medium-r-normal--16-120-100-100-c-80-jisx0201.1976-0
[L][5] -misc-fixed-medium-r-normal--13-120-75-75-c-70-iso10646-1
=======

[M] means "Missing" font, [L] means "Loaded".

On 2018-06-20 23:14, Philip Race wrote:
> My question has not been answered. I don't think this is ready to go 
> in.
> 
> -phil.
> 
> On 6/20/18, 4:23 AM, Ichiroh Takiguchi wrote:
>> Hello.
>> 
>> New fixed code is in:
>> http://cr.openjdk.java.net/~aleonard/defvis/webrev.02/
>> 
>> Could you check fixed files again ?
>> 
>> I only updated following part between webrev.01 and webrev.02
>> ======
>> diff -r 70a582d110a1 -r 6f04164a9d62 
>> src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c
>> --- a/src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c   
>>  Wed Jun 06 21:03:25 2018 +0900
>> +++ b/src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c   
>>  Wed Jun 20 16:54:24 2018 +0900
>> @@ -677,7 +677,7 @@
>>          return NULL;
>>      }
>>      statusWindow->w = status;
>> -    //12-point font
>> +    //12, 13-point fonts
>>      statusWindow->fontset = XCreateFontSet(dpy,
>>                                             
>> "-*-*-medium-r-normal-*-*-120-*-*-*-*," \
>>                                             
>> "-*-*-medium-r-normal-*-*-130-*-*-*-*",
>> ======
>> 
>> 
>> Please create bugid and handle it.
>> 
>> Thanks,
>> Ichiroh Takiguchi
>> IBM Japan, Ltd.
>> 
>> On 2018-06-20 04:59, Naoto Sato wrote:
>>> Please change the comment in line 680, which should also mention 13 
>>> point font.
>>> 
>>> Naoto
>>> 
>>> On 6/19/18 12:54 PM, Naoto Sato wrote:
>>>> Looks OK wrt awt_InputMethod.c change.
>>>> 
>>>> Naoto
>>>> 
>>>> On 6/19/18 11:32 AM, Phil Race wrote:
>>>>> Where's the bug ID ?
>>>>> 
>>>>> The review should have a bug ID in the subject line so we can all 
>>>>> find it later !
>>>>> 
>>>>> Is this changing the default visual  for all WIndows, not just the 
>>>>> IM status window?
>>>>> I think we need to understand the implications before this can be 
>>>>> accepted.
>>>>> 
>>>>> Similarly for the fontset change .. this might change what others 
>>>>> get.
>>>>> The fontset spec. there seems very loose to me ..
>>>>> 
>>>>> I think I18N-DEV should be asked about this too.
>>>>> 
>>>>> -phil.
>>>>> 
>>>>> On 06/19/2018 11:07 AM, Sergey Bylokhov wrote:
>>>>>> Looks fine, if there are no other comments I'll push the fix using 
>>>>>> the new bugid.
>>>>>> 
>>>>>> On 06/06/2018 17:54, Ichiroh Takiguchi wrote:
>>>>>>> Hello Sergey.
>>>>>>> Thank you for your review.
>>>>>>> 
>>>>>>> Could you review following patch ?
>>>>>>> http://cr.openjdk.java.net/~aleonard/defvis/webrev.01/
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> Ichiroh Takiguchi
>>>>>>> IBM Japan, Ltd.
>>>>>>> 
>>>>>>> On 2018-06-06 07:15, Sergey Bylokhov wrote:
>>>>>>>> Hi, Ichiroh.
>>>>>>>> The approach looks fine, but maybe it is possible to decrees 
>>>>>>>> code
>>>>>>>> duplication in findWithTemplate(). After the fix it will have 
>>>>>>>> two
>>>>>>>> similar loops.
>>>>>>>> 
>>>>>>>> On 24/05/2018 22:24, Ichiroh Takiguchi wrote:
>>>>>>>>> Hello,
>>>>>>>>> IBM would like to contribute X11 default visual support for IM 
>>>>>>>>> status window patch to OpenJDK project.
>>>>>>>>> 
>>>>>>>>> Issue:
>>>>>>>>> Java's Native IM status window is not displayed even if it's 
>>>>>>>>> there.
>>>>>>>>> Because of this issue, user cannot get proper visual feedback 
>>>>>>>>> during key input operation.
>>>>>>>>> We found this issue on Tiger VNC.
>>>>>>>>> 
>>>>>>>>> Reason:
>>>>>>>>> Java may pick up unexpected visual for Java's Native IM status 
>>>>>>>>> window when  Xserver supports multiple visual.
>>>>>>>>> 
>>>>>>>>> Workaround:
>>>>>>>>> X11 default visual can be changed by FORCEDEFVIS environment 
>>>>>>>>> variable, but it's not easy to find out default visual id.
>>>>>>>>> 
>>>>>>>>> I'd like contribute following 2 files:
>>>>>>>>> M 
>>>>>>>>> src/java.desktop/unix/native/libawt_xawt/awt/awt_GraphicsEnv.c
>>>>>>>>> (Change X11 visual setting)
>>>>>>>>> M 
>>>>>>>>> src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c
>>>>>>>>> (Support 13 point X11 misc fonts (like k14 font for Japanese), 
>>>>>>>>> since the fonts may defined for unscaled fonts.)
>>>>>>>>> 
>>>>>>>>> webrev files are in
>>>>>>>>> http://cr.openjdk.java.net/~aleonard/defvis/
>>>>>>>>> 
>>>>>>>>> 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 Jun 21 17:21:54 2018
From: naoto.sato at oracle.com (Naoto Sato)
Date: Thu, 21 Jun 2018 10:21:54 -0700
Subject: <i18n dev> [11] Review Request: 8202696 glyphs in textfield
 only shown when thai baht-character is added
In-Reply-To: <1369e2e7-352a-4f6c-9225-d95b5c6e0e6f@default>
References: <17242fed-e6e7-4238-9856-229799ddce1e@default>
 <6cd561e0-fd18-b3ba-7934-57e4cba61441@oracle.com>
 <040f59ee-9c9f-58fb-3b6d-5b2aad3181bf@oracle.com>
 <ce47c811-8fe8-4bcf-923e-c0172992cf5e@default>
 <96579ce3-b499-15bf-1787-97f33113f23d@oracle.com>
 <1369e2e7-352a-4f6c-9225-d95b5c6e0e6f@default>
Message-ID: <5f66cced-d1e9-2966-8e77-f7be4109a2b9@oracle.com>

Hi Dipak,

Please use Locale.toLowerCase(Locale.ROOT) instead of no-arg 
toLowerCase(), as it could fail in tr locale (line 60 in the test case).

Naoto

On 6/18/18 12:29 AM, Dipak Kumar wrote:
> Hi Phil,
> 
> I am able to make the test automated after incorporating your suggestion to limit the test case to logical fonts.
> I observed that "canDisplayUpTo()" which internally uses "canDisplay()" does return expected values for logical fonts.
> 
> Thanks for your guidance.
> 
> Please find the updated webrev at http://cr.openjdk.java.net/~dkumar/8202696/webrev.02/ .
> Request you to review it again and let me know your comments.
> 
> Thanks,
> Dipak
> 
> -----Original Message-----
> From: Phil Race
> Sent: 16 June 2018 00:11
> To: Dipak Kumar <dipak.kumar at oracle.com>; 2d-dev at openjdk.java.net; i18n-dev at openjdk.java.net; Naoto Sato <naoto.sato at oracle.com>
> Subject: Re: [11] Review Request: 8202696 glyphs in textfield only shown when thai baht-character is added
> 
> The exclusion ranges only apply to the logical fonts, so the iteration you are doing looking for any font is now not testing the case you are trying to fix, except by chance. You will need to limit the iteration to the logical fonts.
> 
> I don't know why canDisplay(..) did not do what I would expect ..
> particularly
> since canDisplayUpTo should be using the same information.
> 
> -phil.
> 
> On 06/14/2018 12:07 AM, Dipak Kumar wrote:
>> Hi Phil,
>>
>> Thanks for reviewing the patch and providing useful information.
>> Regarding your suggestion of using "canDisplay()" in test, I tried using this function to make the test headless.
>> But this function is returning true even without proposed fix in fontconfig.properties file. Font exclusion is not coming into picture in this function call.
>>
>> In the previously written test case, I have added a check for font support (whether characters can be displayed or not using function "canDisplayUpTo()").
>> Please find the updated webrev at http://cr.openjdk.java.net/~dkumar/8202696/webrev.01/ .
>>
>> Request you to have a look into this again and let me know your inputs.
>>
>> Many thanks,
>> Dipak
>>
>> -----Original Message-----
>> From: Phil Race
>> Sent: 13 June 2018 03:26
>> To: Dipak Kumar <dipak.kumar at oracle.com>; 2d-dev at openjdk.java.net;
>> i18n-dev at openjdk.java.net; Naoto Sato <naoto.sato at oracle.com>
>> Subject: Re: [11] Review Request: 8202696 glyphs in textfield only
>> shown when thai baht-character is added
>>
>> BTW I think the synopsis really needs updating !
>>
>> Once you know what is going on, continuing to title it after the random empirical observation of the reporter is not necessary. I've changed it to :
>>
>> "Remove exclusion range for phonetic chars in windows fontconfig.properties"
>>
>> Please use that in the commit - when you get to it.
>>
>> -phil.
>>
>> On 06/12/2018 01:46 PM, Phil Race wrote:
>>> I can only guess why this range was excluded.
>>> My guess is that it was something to do with an attempt at allowing
>>> as many of these glyphs as possible to come from (for example) a
>>> Chinese font in a chinese locale even though we always put the latin
>>> font first ..
>>>
>>> The interesting reason why adding a Thai Baht magically makes them
>>> appears is Thai forces TextLayout .. and it (apparently) bypasses the
>>> exclusion range.
>>> I suspect this is because layout needs to operate on physical fonts
>>> so gets the list of physical fonts and operates on these explicitly
>>> bypassing CompositeFont which is where this support exists.
>>> You can prove that just by using one of these phonetic chars in
>>> Font2DTest without adding Thai or anything else and switching to
>>> TextLayout .. lo and behold .. it appears.
>>> I wonder how long that has been the case ? Perhaps so long as to be
>>> effectively forever ..
>>>
>>> That makes a case for getting rid of all these ranges.
>>> The use for the ranges is to control what physical font is used for
>>> glyphs in cases where some font that may be "earlier" in the list
>>> supplies glyphs that you'd actually prefer to come from some other
>>> font.
>>> That may be useful if the exclusion ranges were able to be applied
>>> depending on your locale, but this alphabetic exclusion is
>>> particularly questionable.
>>>
>>> So the change is OK, but can't the test be automated .. and headless ?
>>> You just need to do something like ask if the font "canDisplay()"
>>> these code points.
>>> However the test is fragile in the sense that it assumes that logical
>>> fonts on Windows are capable of supporting them.
>>>
>>> -phil
>>>
>>>
>>> On 06/04/2018 11:32 PM, Dipak Kumar wrote:
>>>> Hi,
>>>>
>>>> Please review below fix :
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8202696
>>>> Webrev: http://cr.openjdk.java.net/~dkumar/8202696/webrev.00/
>>>>
>>>> Characters which are not getting displayed actually belong to
>>>> Phonetic Extensions
>>>> (https://en.wikipedia.org/wiki/Phonetic_Extensions ).
>>>> These characters are not getting rendered properly because they are
>>>> in exclusion range mentioned in the windows.fontconfig.properties file.
>>>> In the above fix, font exclusion ranges have been adjusted so that
>>>> these characters do not fall within these ranges
>>>>
>>>> Font related Jtreg tests and Mach5 client tests are fine.
>>>>
>>>> Thanks,
>>>> Dipak
> 

From dipak.kumar at oracle.com  Fri Jun 22 04:52:17 2018
From: dipak.kumar at oracle.com (Dipak Kumar)
Date: Thu, 21 Jun 2018 21:52:17 -0700 (PDT)
Subject: <i18n dev> [11] Review Request: 8202696 glyphs in textfield
 only shown when thai baht-character is added
In-Reply-To: <5f66cced-d1e9-2966-8e77-f7be4109a2b9@oracle.com>
References: <17242fed-e6e7-4238-9856-229799ddce1e@default>
 <6cd561e0-fd18-b3ba-7934-57e4cba61441@oracle.com>
 <040f59ee-9c9f-58fb-3b6d-5b2aad3181bf@oracle.com>
 <ce47c811-8fe8-4bcf-923e-c0172992cf5e@default>
 <96579ce3-b499-15bf-1787-97f33113f23d@oracle.com>
 <1369e2e7-352a-4f6c-9225-d95b5c6e0e6f@default>
 <5f66cced-d1e9-2966-8e77-f7be4109a2b9@oracle.com>
Message-ID: <46302f61-3f89-4580-9fcf-5e7a09534d55@default>

Hi Naoto,

Thanks for the review. 
I have incorporated your suggestion and please find the updated webrev at http://cr.openjdk.java.net/~dkumar/8202696/webrev.03/ .
Request you to have a look at it again and let me know your comments.

Thanks,
Dipak


-----Original Message-----
From: Naoto Sato 
Sent: 21 June 2018 22:52
To: Dipak Kumar <dipak.kumar at oracle.com>; Philip Race <philip.race at oracle.com>; 2d-dev at openjdk.java.net; i18n-dev at openjdk.java.net
Subject: Re: [11] Review Request: 8202696 glyphs in textfield only shown when thai baht-character is added

Hi Dipak,

Please use Locale.toLowerCase(Locale.ROOT) instead of no-arg toLowerCase(), as it could fail in tr locale (line 60 in the test case).

Naoto

On 6/18/18 12:29 AM, Dipak Kumar wrote:
> Hi Phil,
> 
> I am able to make the test automated after incorporating your suggestion to limit the test case to logical fonts.
> I observed that "canDisplayUpTo()" which internally uses "canDisplay()" does return expected values for logical fonts.
> 
> Thanks for your guidance.
> 
> Please find the updated webrev at http://cr.openjdk.java.net/~dkumar/8202696/webrev.02/ .
> Request you to review it again and let me know your comments.
> 
> Thanks,
> Dipak
> 
> -----Original Message-----
> From: Phil Race
> Sent: 16 June 2018 00:11
> To: Dipak Kumar <dipak.kumar at oracle.com>; 2d-dev at openjdk.java.net; 
> i18n-dev at openjdk.java.net; Naoto Sato <naoto.sato at oracle.com>
> Subject: Re: [11] Review Request: 8202696 glyphs in textfield only 
> shown when thai baht-character is added
> 
> The exclusion ranges only apply to the logical fonts, so the iteration you are doing looking for any font is now not testing the case you are trying to fix, except by chance. You will need to limit the iteration to the logical fonts.
> 
> I don't know why canDisplay(..) did not do what I would expect ..
> particularly
> since canDisplayUpTo should be using the same information.
> 
> -phil.
> 
> On 06/14/2018 12:07 AM, Dipak Kumar wrote:
>> Hi Phil,
>>
>> Thanks for reviewing the patch and providing useful information.
>> Regarding your suggestion of using "canDisplay()" in test, I tried using this function to make the test headless.
>> But this function is returning true even without proposed fix in fontconfig.properties file. Font exclusion is not coming into picture in this function call.
>>
>> In the previously written test case, I have added a check for font support (whether characters can be displayed or not using function "canDisplayUpTo()").
>> Please find the updated webrev at http://cr.openjdk.java.net/~dkumar/8202696/webrev.01/ .
>>
>> Request you to have a look into this again and let me know your inputs.
>>
>> Many thanks,
>> Dipak
>>
>> -----Original Message-----
>> From: Phil Race
>> Sent: 13 June 2018 03:26
>> To: Dipak Kumar <dipak.kumar at oracle.com>; 2d-dev at openjdk.java.net; 
>> i18n-dev at openjdk.java.net; Naoto Sato <naoto.sato at oracle.com>
>> Subject: Re: [11] Review Request: 8202696 glyphs in textfield only 
>> shown when thai baht-character is added
>>
>> BTW I think the synopsis really needs updating !
>>
>> Once you know what is going on, continuing to title it after the random empirical observation of the reporter is not necessary. I've changed it to :
>>
>> "Remove exclusion range for phonetic chars in windows fontconfig.properties"
>>
>> Please use that in the commit - when you get to it.
>>
>> -phil.
>>
>> On 06/12/2018 01:46 PM, Phil Race wrote:
>>> I can only guess why this range was excluded.
>>> My guess is that it was something to do with an attempt at allowing 
>>> as many of these glyphs as possible to come from (for example) a 
>>> Chinese font in a chinese locale even though we always put the latin 
>>> font first ..
>>>
>>> The interesting reason why adding a Thai Baht magically makes them 
>>> appears is Thai forces TextLayout .. and it (apparently) bypasses 
>>> the exclusion range.
>>> I suspect this is because layout needs to operate on physical fonts 
>>> so gets the list of physical fonts and operates on these explicitly 
>>> bypassing CompositeFont which is where this support exists.
>>> You can prove that just by using one of these phonetic chars in 
>>> Font2DTest without adding Thai or anything else and switching to 
>>> TextLayout .. lo and behold .. it appears.
>>> I wonder how long that has been the case ? Perhaps so long as to be 
>>> effectively forever ..
>>>
>>> That makes a case for getting rid of all these ranges.
>>> The use for the ranges is to control what physical font is used for 
>>> glyphs in cases where some font that may be "earlier" in the list 
>>> supplies glyphs that you'd actually prefer to come from some other 
>>> font.
>>> That may be useful if the exclusion ranges were able to be applied 
>>> depending on your locale, but this alphabetic exclusion is 
>>> particularly questionable.
>>>
>>> So the change is OK, but can't the test be automated .. and headless ?
>>> You just need to do something like ask if the font "canDisplay()"
>>> these code points.
>>> However the test is fragile in the sense that it assumes that 
>>> logical fonts on Windows are capable of supporting them.
>>>
>>> -phil
>>>
>>>
>>> On 06/04/2018 11:32 PM, Dipak Kumar wrote:
>>>> Hi,
>>>>
>>>> Please review below fix :
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8202696
>>>> Webrev: http://cr.openjdk.java.net/~dkumar/8202696/webrev.00/
>>>>
>>>> Characters which are not getting displayed actually belong to 
>>>> Phonetic Extensions 
>>>> (https://en.wikipedia.org/wiki/Phonetic_Extensions ).
>>>> These characters are not getting rendered properly because they are 
>>>> in exclusion range mentioned in the windows.fontconfig.properties file.
>>>> In the above fix, font exclusion ranges have been adjusted so that 
>>>> these characters do not fall within these ranges
>>>>
>>>> Font related Jtreg tests and Mach5 client tests are fine.
>>>>
>>>> Thanks,
>>>> Dipak
> 

From philip.race at oracle.com  Fri Jun 22 05:03:44 2018
From: philip.race at oracle.com (Philip Race)
Date: Thu, 21 Jun 2018 22:03:44 -0700
Subject: <i18n dev> [11] Review Request: 8202696 glyphs in textfield
 only shown when thai baht-character is added
In-Reply-To: <46302f61-3f89-4580-9fcf-5e7a09534d55@default>
References: <17242fed-e6e7-4238-9856-229799ddce1e@default>
 <6cd561e0-fd18-b3ba-7934-57e4cba61441@oracle.com>
 <040f59ee-9c9f-58fb-3b6d-5b2aad3181bf@oracle.com>
 <ce47c811-8fe8-4bcf-923e-c0172992cf5e@default>
 <96579ce3-b499-15bf-1787-97f33113f23d@oracle.com>
 <1369e2e7-352a-4f6c-9225-d95b5c6e0e6f@default>
 <5f66cced-d1e9-2966-8e77-f7be4109a2b9@oracle.com>
 <46302f61-3f89-4580-9fcf-5e7a09534d55@default>
Message-ID: <5B2C8330.1070708@oracle.com>

We don't run the tests in a turkish locale, like we don't build in that 
locale,
so it is not expected in general, so it was OK already, but this is 
still fine by me.

-phil.

On 6/21/18, 9:52 PM, Dipak Kumar wrote:
> Hi Naoto,
>
> Thanks for the review.
> I have incorporated your suggestion and please find the updated webrev at http://cr.openjdk.java.net/~dkumar/8202696/webrev.03/ .
> Request you to have a look at it again and let me know your comments.
>
> Thanks,
> Dipak
>
>
> -----Original Message-----
> From: Naoto Sato
> Sent: 21 June 2018 22:52
> To: Dipak Kumar<dipak.kumar at oracle.com>; Philip Race<philip.race at oracle.com>; 2d-dev at openjdk.java.net; i18n-dev at openjdk.java.net
> Subject: Re: [11] Review Request: 8202696 glyphs in textfield only shown when thai baht-character is added
>
> Hi Dipak,
>
> Please use Locale.toLowerCase(Locale.ROOT) instead of no-arg toLowerCase(), as it could fail in tr locale (line 60 in the test case).
>
> Naoto
>
> On 6/18/18 12:29 AM, Dipak Kumar wrote:
>> Hi Phil,
>>
>> I am able to make the test automated after incorporating your suggestion to limit the test case to logical fonts.
>> I observed that "canDisplayUpTo()" which internally uses "canDisplay()" does return expected values for logical fonts.
>>
>> Thanks for your guidance.
>>
>> Please find the updated webrev at http://cr.openjdk.java.net/~dkumar/8202696/webrev.02/ .
>> Request you to review it again and let me know your comments.
>>
>> Thanks,
>> Dipak
>>
>> -----Original Message-----
>> From: Phil Race
>> Sent: 16 June 2018 00:11
>> To: Dipak Kumar<dipak.kumar at oracle.com>; 2d-dev at openjdk.java.net;
>> i18n-dev at openjdk.java.net; Naoto Sato<naoto.sato at oracle.com>
>> Subject: Re: [11] Review Request: 8202696 glyphs in textfield only
>> shown when thai baht-character is added
>>
>> The exclusion ranges only apply to the logical fonts, so the iteration you are doing looking for any font is now not testing the case you are trying to fix, except by chance. You will need to limit the iteration to the logical fonts.
>>
>> I don't know why canDisplay(..) did not do what I would expect ..
>> particularly
>> since canDisplayUpTo should be using the same information.
>>
>> -phil.
>>
>> On 06/14/2018 12:07 AM, Dipak Kumar wrote:
>>> Hi Phil,
>>>
>>> Thanks for reviewing the patch and providing useful information.
>>> Regarding your suggestion of using "canDisplay()" in test, I tried using this function to make the test headless.
>>> But this function is returning true even without proposed fix in fontconfig.properties file. Font exclusion is not coming into picture in this function call.
>>>
>>> In the previously written test case, I have added a check for font support (whether characters can be displayed or not using function "canDisplayUpTo()").
>>> Please find the updated webrev at http://cr.openjdk.java.net/~dkumar/8202696/webrev.01/ .
>>>
>>> Request you to have a look into this again and let me know your inputs.
>>>
>>> Many thanks,
>>> Dipak
>>>
>>> -----Original Message-----
>>> From: Phil Race
>>> Sent: 13 June 2018 03:26
>>> To: Dipak Kumar<dipak.kumar at oracle.com>; 2d-dev at openjdk.java.net;
>>> i18n-dev at openjdk.java.net; Naoto Sato<naoto.sato at oracle.com>
>>> Subject: Re: [11] Review Request: 8202696 glyphs in textfield only
>>> shown when thai baht-character is added
>>>
>>> BTW I think the synopsis really needs updating !
>>>
>>> Once you know what is going on, continuing to title it after the random empirical observation of the reporter is not necessary. I've changed it to :
>>>
>>> "Remove exclusion range for phonetic chars in windows fontconfig.properties"
>>>
>>> Please use that in the commit - when you get to it.
>>>
>>> -phil.
>>>
>>> On 06/12/2018 01:46 PM, Phil Race wrote:
>>>> I can only guess why this range was excluded.
>>>> My guess is that it was something to do with an attempt at allowing
>>>> as many of these glyphs as possible to come from (for example) a
>>>> Chinese font in a chinese locale even though we always put the latin
>>>> font first ..
>>>>
>>>> The interesting reason why adding a Thai Baht magically makes them
>>>> appears is Thai forces TextLayout .. and it (apparently) bypasses
>>>> the exclusion range.
>>>> I suspect this is because layout needs to operate on physical fonts
>>>> so gets the list of physical fonts and operates on these explicitly
>>>> bypassing CompositeFont which is where this support exists.
>>>> You can prove that just by using one of these phonetic chars in
>>>> Font2DTest without adding Thai or anything else and switching to
>>>> TextLayout .. lo and behold .. it appears.
>>>> I wonder how long that has been the case ? Perhaps so long as to be
>>>> effectively forever ..
>>>>
>>>> That makes a case for getting rid of all these ranges.
>>>> The use for the ranges is to control what physical font is used for
>>>> glyphs in cases where some font that may be "earlier" in the list
>>>> supplies glyphs that you'd actually prefer to come from some other
>>>> font.
>>>> That may be useful if the exclusion ranges were able to be applied
>>>> depending on your locale, but this alphabetic exclusion is
>>>> particularly questionable.
>>>>
>>>> So the change is OK, but can't the test be automated .. and headless ?
>>>> You just need to do something like ask if the font "canDisplay()"
>>>> these code points.
>>>> However the test is fragile in the sense that it assumes that
>>>> logical fonts on Windows are capable of supporting them.
>>>>
>>>> -phil
>>>>
>>>>
>>>> On 06/04/2018 11:32 PM, Dipak Kumar wrote:
>>>>> Hi,
>>>>>
>>>>> Please review below fix :
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8202696
>>>>> Webrev: http://cr.openjdk.java.net/~dkumar/8202696/webrev.00/
>>>>>
>>>>> Characters which are not getting displayed actually belong to
>>>>> Phonetic Extensions
>>>>> (https://en.wikipedia.org/wiki/Phonetic_Extensions ).
>>>>> These characters are not getting rendered properly because they are
>>>>> in exclusion range mentioned in the windows.fontconfig.properties file.
>>>>> In the above fix, font exclusion ranges have been adjusted so that
>>>>> these characters do not fall within these ranges
>>>>>
>>>>> Font related Jtreg tests and Mach5 client tests are fine.
>>>>>
>>>>> Thanks,
>>>>> Dipak

From dan.z.zhou at oracle.com  Fri Jun 22 08:26:17 2018
From: dan.z.zhou at oracle.com (Dora Zhou)
Date: Fri, 22 Jun 2018 16:26:17 +0800
Subject: <i18n dev> [11]RFR 8194152:
 sun/security/tools/jarsigner/AltProvider.java failed on de-DE locale
Message-ID: <09f92268-fe4d-3c57-0ffb-d93d9703974d@oracle.com>

Hello,

Please help review the fix for JDK-8194152. Thank you.

The test compares output with expected error messages in English, set 
locale to en-US so that the output are not translated into other languages.

Bug: https://bugs.openjdk.java.net/browse/JDK-8194152
Webrev: http://cr.openjdk.java.net/~ljiang/8194152/webrev/ 
<http://cr.openjdk.java.net/%7Eljiang/8194152/webrev/>

Regards,
Dora

From takiguc at linux.vnet.ibm.com  Fri Jun 22 12:13:25 2018
From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi)
Date: Fri, 22 Jun 2018 21:13:25 +0900
Subject: <i18n dev> Proposal: Reverse attribute remains incorrectly with
	Input Method
Message-ID: <c72de08ffbed6047f38286706a7cb230@linux.vnet.ibm.com>

Hello,
IBM would like to contribute a patch to OpenJDK project.

We'd like to propose a fix of Input Method relating problem.
Can we have a sponsor of the patch?

Problem:
When Input Method's preedit text and text selection were mixed, the 
reverse attribute of selection remained unexpectedly.

Recreate steps:
1. On Japanese locale, start Notepad java demo program
2. Type "123456", and move caret between "4" and "5"
3. Turn on Input Method. type "aiu" (Japanese characters) and keep 
preedit (without committing).
    ("123aiu456" should be displayed)
4. Drag (select) "aiu456" by mouse.
       (If you click out side of preedit text, it will be committed.)
5. Move focus to other window, then move the focus back.
    Preedit text was canceled, and the reverse attribute remained on 
"456".
6. Turn off Input Method, move caret before "1".
    The reverse attribute was cleared.
7. Type "0",  the reverse attribute was still remaining.
(With Input Method, the attribute can delete since preedit string has an 
attribute.)

Candidate fix:
----------
--- 
old/src/java.desktop/share/classes/javax/swing/text/JTextComponent.java  
       2018-06-22 21:01:05.367309169 +0900
+++ 
new/src/java.desktop/share/classes/javax/swing/text/JTextComponent.java  
       2018-06-22 21:01:04.745322344 +0900
@@ -5000,6 +5000,7 @@
              caret.setDot(dot);
          } else if (caret instanceof ComposedTextCaret) {
              dot = caret.getDot();
+            select(dot, dot);
              // Restores original caret
              exchangeCaret(caret, originalCaret);
              caret.setDot(dot);
----------

Thanks,
Ichiroh Takiguchi
IBM Japan, Ltd.


From naoto.sato at oracle.com  Fri Jun 22 12:11:35 2018
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Fri, 22 Jun 2018 05:11:35 -0700
Subject: <i18n dev> [11] Review Request: 8202696 glyphs in textfield
 only shown when thai baht-character is added
In-Reply-To: <5f66cced-d1e9-2966-8e77-f7be4109a2b9@oracle.com>
References: <17242fed-e6e7-4238-9856-229799ddce1e@default>
 <6cd561e0-fd18-b3ba-7934-57e4cba61441@oracle.com>
 <040f59ee-9c9f-58fb-3b6d-5b2aad3181bf@oracle.com>
 <ce47c811-8fe8-4bcf-923e-c0172992cf5e@default>
 <96579ce3-b499-15bf-1787-97f33113f23d@oracle.com>
 <1369e2e7-352a-4f6c-9225-d95b5c6e0e6f@default>
 <5f66cced-d1e9-2966-8e77-f7be4109a2b9@oracle.com>
Message-ID: <d0a690c6-f60c-aa67-09f3-d6a15fc3763b@oracle.com>

Looks good.

Naoto

On 6/21/18 10:21 AM, Naoto Sato wrote:
> Hi Dipak,
> 
> Please use Locale.toLowerCase(Locale.ROOT) instead of no-arg 
> toLowerCase(), as it could fail in tr locale (line 60 in the test case).
> 
> Naoto
> 
> On 6/18/18 12:29 AM, Dipak Kumar wrote:
>> Hi Phil,
>>
>> I am able to make the test automated after incorporating your 
>> suggestion to limit the test case to logical fonts.
>> I observed that "canDisplayUpTo()" which internally uses 
>> "canDisplay()" does return expected values for logical fonts.
>>
>> Thanks for your guidance.
>>
>> Please find the updated webrev at 
>> http://cr.openjdk.java.net/~dkumar/8202696/webrev.02/ .
>> Request you to review it again and let me know your comments.
>>
>> Thanks,
>> Dipak
>>
>> -----Original Message-----
>> From: Phil Race
>> Sent: 16 June 2018 00:11
>> To: Dipak Kumar <dipak.kumar at oracle.com>; 2d-dev at openjdk.java.net; 
>> i18n-dev at openjdk.java.net; Naoto Sato <naoto.sato at oracle.com>
>> Subject: Re: [11] Review Request: 8202696 glyphs in textfield only 
>> shown when thai baht-character is added
>>
>> The exclusion ranges only apply to the logical fonts, so the iteration 
>> you are doing looking for any font is now not testing the case you are 
>> trying to fix, except by chance. You will need to limit the iteration 
>> to the logical fonts.
>>
>> I don't know why canDisplay(..) did not do what I would expect ..
>> particularly
>> since canDisplayUpTo should be using the same information.
>>
>> -phil.
>>
>> On 06/14/2018 12:07 AM, Dipak Kumar wrote:
>>> Hi Phil,
>>>
>>> Thanks for reviewing the patch and providing useful information.
>>> Regarding your suggestion of using "canDisplay()" in test, I tried 
>>> using this function to make the test headless.
>>> But this function is returning true even without proposed fix in 
>>> fontconfig.properties file. Font exclusion is not coming into picture 
>>> in this function call.
>>>
>>> In the previously written test case, I have added a check for font 
>>> support (whether characters can be displayed or not using function 
>>> "canDisplayUpTo()").
>>> Please find the updated webrev at 
>>> http://cr.openjdk.java.net/~dkumar/8202696/webrev.01/ .
>>>
>>> Request you to have a look into this again and let me know your inputs.
>>>
>>> Many thanks,
>>> Dipak
>>>
>>> -----Original Message-----
>>> From: Phil Race
>>> Sent: 13 June 2018 03:26
>>> To: Dipak Kumar <dipak.kumar at oracle.com>; 2d-dev at openjdk.java.net;
>>> i18n-dev at openjdk.java.net; Naoto Sato <naoto.sato at oracle.com>
>>> Subject: Re: [11] Review Request: 8202696 glyphs in textfield only
>>> shown when thai baht-character is added
>>>
>>> BTW I think the synopsis really needs updating !
>>>
>>> Once you know what is going on, continuing to title it after the 
>>> random empirical observation of the reporter is not necessary. I've 
>>> changed it to :
>>>
>>> "Remove exclusion range for phonetic chars in windows 
>>> fontconfig.properties"
>>>
>>> Please use that in the commit - when you get to it.
>>>
>>> -phil.
>>>
>>> On 06/12/2018 01:46 PM, Phil Race wrote:
>>>> I can only guess why this range was excluded.
>>>> My guess is that it was something to do with an attempt at allowing
>>>> as many of these glyphs as possible to come from (for example) a
>>>> Chinese font in a chinese locale even though we always put the latin
>>>> font first ..
>>>>
>>>> The interesting reason why adding a Thai Baht magically makes them
>>>> appears is Thai forces TextLayout .. and it (apparently) bypasses the
>>>> exclusion range.
>>>> I suspect this is because layout needs to operate on physical fonts
>>>> so gets the list of physical fonts and operates on these explicitly
>>>> bypassing CompositeFont which is where this support exists.
>>>> You can prove that just by using one of these phonetic chars in
>>>> Font2DTest without adding Thai or anything else and switching to
>>>> TextLayout .. lo and behold .. it appears.
>>>> I wonder how long that has been the case ? Perhaps so long as to be
>>>> effectively forever ..
>>>>
>>>> That makes a case for getting rid of all these ranges.
>>>> The use for the ranges is to control what physical font is used for
>>>> glyphs in cases where some font that may be "earlier" in the list
>>>> supplies glyphs that you'd actually prefer to come from some other
>>>> font.
>>>> That may be useful if the exclusion ranges were able to be applied
>>>> depending on your locale, but this alphabetic exclusion is
>>>> particularly questionable.
>>>>
>>>> So the change is OK, but can't the test be automated .. and headless ?
>>>> You just need to do something like ask if the font "canDisplay()"
>>>> these code points.
>>>> However the test is fragile in the sense that it assumes that logical
>>>> fonts on Windows are capable of supporting them.
>>>>
>>>> -phil
>>>>
>>>>
>>>> On 06/04/2018 11:32 PM, Dipak Kumar wrote:
>>>>> Hi,
>>>>>
>>>>> Please review below fix :
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8202696
>>>>> Webrev: http://cr.openjdk.java.net/~dkumar/8202696/webrev.00/
>>>>>
>>>>> Characters which are not getting displayed actually belong to
>>>>> Phonetic Extensions
>>>>> (https://en.wikipedia.org/wiki/Phonetic_Extensions ).
>>>>> These characters are not getting rendered properly because they are
>>>>> in exclusion range mentioned in the windows.fontconfig.properties 
>>>>> file.
>>>>> In the above fix, font exclusion ranges have been adjusted so that
>>>>> these characters do not fall within these ranges
>>>>>
>>>>> Font related Jtreg tests and Mach5 client tests are fine.
>>>>>
>>>>> Thanks,
>>>>> Dipak
>>

From rachna.goel at oracle.com  Fri Jun 22 13:54:15 2018
From: rachna.goel at oracle.com (Rachna Goel)
Date: Fri, 22 Jun 2018 19:24:15 +0530
Subject: <i18n dev> RFR: JDK-8205158: Update the .md files for 3rd party
 software Unicode 10.0, ICU 60.1, and CLDR v33
Message-ID: <c1625320-ccbd-e21f-91af-97a571960c8c@oracle.com>

Hi,

Kindly review fix to update legal files for Unicode, CLDR and ICU.

Issue: https://bugs.openjdk.java.net/browse/JDK-8205158

Patch :http://cr.openjdk.java.net/~rgoel/JDK-8205158/webrev.02/

-- 
Thanks,
Rachna


From mandy.chung at oracle.com  Fri Jun 22 16:27:35 2018
From: mandy.chung at oracle.com (mandy chung)
Date: Fri, 22 Jun 2018 09:27:35 -0700
Subject: <i18n dev> RFR: JDK-8205158: Update the .md files for 3rd party
 software Unicode 10.0, ICU 60.1, and CLDR v33
In-Reply-To: <c1625320-ccbd-e21f-91af-97a571960c8c@oracle.com>
References: <c1625320-ccbd-e21f-91af-97a571960c8c@oracle.com>
Message-ID: <34b3c8c1-f8fc-77ce-7dd9-eac6071bcd97@oracle.com>



On 6/22/18 6:54 AM, Rachna Goel wrote:
> Hi,
> 
> Kindly review fix to update legal files for Unicode, CLDR and ICU.
> 
> Issue: https://bugs.openjdk.java.net/browse/JDK-8205158
> 
> Patch :http://cr.openjdk.java.net/~rgoel/JDK-8205158/webrev.02/

Looks okay.

What are the issues that upgrades these libraries?  Can you link them 
with JDK-8205158?

Mandy

From rachna.goel at oracle.com  Fri Jun 22 16:28:20 2018
From: rachna.goel at oracle.com (Rachna Goel)
Date: Fri, 22 Jun 2018 21:58:20 +0530
Subject: <i18n dev> RFR: JDK-8205158: Update the .md files for 3rd party
 software Unicode 10.0, ICU 60.1, and CLDR v33
In-Reply-To: <c1625320-ccbd-e21f-91af-97a571960c8c@oracle.com>
References: <c1625320-ccbd-e21f-91af-97a571960c8c@oracle.com>
Message-ID: <7e48ad45-77f5-0176-246f-5857fce57127@oracle.com>

Hi,

Kindly ignore patch mentioned in previous mail.

patch for review is : 
http://cr.openjdk.java.net/~rgoel/JDK-8205158/webrev.01/

Thanks,

Rachna


On 6/22/18 7:24 PM, Rachna Goel wrote:
> Hi,
>
> Kindly review fix to update legal files for Unicode, CLDR and ICU.
>
> Issue: https://bugs.openjdk.java.net/browse/JDK-8205158
>
> Patch :http://cr.openjdk.java.net/~rgoel/JDK-8205158/webrev.02/
>

-- 
Thanks,
Rachna


From rachna.goel at oracle.com  Fri Jun 22 16:34:48 2018
From: rachna.goel at oracle.com (Rachna Goel)
Date: Fri, 22 Jun 2018 22:04:48 +0530
Subject: <i18n dev> RFR: JDK-8205158: Update the .md files for 3rd party
 software Unicode 10.0, ICU 60.1, and CLDR v33
In-Reply-To: <34b3c8c1-f8fc-77ce-7dd9-eac6071bcd97@oracle.com>
References: <c1625320-ccbd-e21f-91af-97a571960c8c@oracle.com>
 <34b3c8c1-f8fc-77ce-7dd9-eac6071bcd97@oracle.com>
Message-ID: <e5c471f4-5ce6-9746-6a2f-7acdf55560ed@oracle.com>

Hi Mandy,

Thanks for the review.

Unicode 10.0.0 and ICU 60.2 were integrated with : 
https://bugs.openjdk.java.net/browse/JDK-8191410

and CLDR 33 was: https://bugs.openjdk.java.net/browse/JDK-8202537

Linked mentioned issues with this one.

Thanks,

Rachna


On 6/22/18 9:57 PM, mandy chung wrote:
>
>
> On 6/22/18 6:54 AM, Rachna Goel wrote:
>> Hi,
>>
>> Kindly review fix to update legal files for Unicode, CLDR and ICU.
>>
>> Issue: https://bugs.openjdk.java.net/browse/JDK-8205158
>>
>> Patch :http://cr.openjdk.java.net/~rgoel/JDK-8205158/webrev.02/
>
> Looks okay.
>
> What are the issues that upgrades these libraries?  Can you link them 
> with JDK-8205158?
>
> Mandy

-- 
Thanks,
Rachna


From mandy.chung at oracle.com  Fri Jun 22 16:55:25 2018
From: mandy.chung at oracle.com (mandy chung)
Date: Fri, 22 Jun 2018 09:55:25 -0700
Subject: <i18n dev> RFR: JDK-8205158: Update the .md files for 3rd party
 software Unicode 10.0, ICU 60.1, and CLDR v33
In-Reply-To: <e5c471f4-5ce6-9746-6a2f-7acdf55560ed@oracle.com>
References: <c1625320-ccbd-e21f-91af-97a571960c8c@oracle.com>
 <34b3c8c1-f8fc-77ce-7dd9-eac6071bcd97@oracle.com>
 <e5c471f4-5ce6-9746-6a2f-7acdf55560ed@oracle.com>
Message-ID: <3157f641-64f7-cf45-8f1e-0b628aa4ccbc@oracle.com>

webrev.01 looks better and it wraps long lines.

Mandy

On 6/22/18 9:34 AM, Rachna Goel wrote:
> Hi Mandy,
> 
> Thanks for the review.
> 
> Unicode 10.0.0 and ICU 60.2 were integrated with : 
> https://bugs.openjdk.java.net/browse/JDK-8191410
> 
> and CLDR 33 was: https://bugs.openjdk.java.net/browse/JDK-8202537
> 
> Linked mentioned issues with this one.
> 
> Thanks,
> 
> Rachna
> 
> 
> On 6/22/18 9:57 PM, mandy chung wrote:
>>
>>
>> On 6/22/18 6:54 AM, Rachna Goel wrote:
>>> Hi,
>>>
>>> Kindly review fix to update legal files for Unicode, CLDR and ICU.
>>>
>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8205158
>>>
>>> Patch :http://cr.openjdk.java.net/~rgoel/JDK-8205158/webrev.02/
>>
>> Looks okay.
>>
>> What are the issues that upgrades these libraries?? Can you link them 
>> with JDK-8205158?
>>
>> Mandy
> 
> -- 
> Thanks,
> Rachna
> 

From naoto.sato at oracle.com  Fri Jun 22 17:10:05 2018
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Fri, 22 Jun 2018 10:10:05 -0700
Subject: <i18n dev> RFR: JDK-8205158: Update the .md files for 3rd party
 software Unicode 10.0, ICU 60.1, and CLDR v33
In-Reply-To: <3157f641-64f7-cf45-8f1e-0b628aa4ccbc@oracle.com>
References: <c1625320-ccbd-e21f-91af-97a571960c8c@oracle.com>
 <34b3c8c1-f8fc-77ce-7dd9-eac6071bcd97@oracle.com>
 <e5c471f4-5ce6-9746-6a2f-7acdf55560ed@oracle.com>
 <3157f641-64f7-cf45-8f1e-0b628aa4ccbc@oracle.com>
Message-ID: <b7645140-bcd3-03cf-76a7-fff4ec0b0183@oracle.com>

+1

Naoto

On 6/22/18 9:55 AM, mandy chung wrote:
> webrev.01 looks better and it wraps long lines.
> 
> Mandy
> 
> On 6/22/18 9:34 AM, Rachna Goel wrote:
>> Hi Mandy,
>>
>> Thanks for the review.
>>
>> Unicode 10.0.0 and ICU 60.2 were integrated with : 
>> https://bugs.openjdk.java.net/browse/JDK-8191410
>>
>> and CLDR 33 was: https://bugs.openjdk.java.net/browse/JDK-8202537
>>
>> Linked mentioned issues with this one.
>>
>> Thanks,
>>
>> Rachna
>>
>>
>> On 6/22/18 9:57 PM, mandy chung wrote:
>>>
>>>
>>> On 6/22/18 6:54 AM, Rachna Goel wrote:
>>>> Hi,
>>>>
>>>> Kindly review fix to update legal files for Unicode, CLDR and ICU.
>>>>
>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8205158
>>>>
>>>> Patch :http://cr.openjdk.java.net/~rgoel/JDK-8205158/webrev.02/
>>>
>>> Looks okay.
>>>
>>> What are the issues that upgrades these libraries?? Can you link them 
>>> with JDK-8205158?
>>>
>>> Mandy
>>
>> -- 
>> Thanks,
>> Rachna
>>

From naoto.sato at oracle.com  Fri Jun 22 17:26:17 2018
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Fri, 22 Jun 2018 10:26:17 -0700
Subject: <i18n dev> [11]RFR 8194152:
 sun/security/tools/jarsigner/AltProvider.java failed on de-DE locale
In-Reply-To: <09f92268-fe4d-3c57-0ffb-d93d9703974d@oracle.com>
References: <09f92268-fe4d-3c57-0ffb-d93d9703974d@oracle.com>
Message-ID: <c5ae7434-12a0-c799-9848-25df6a97c192@oracle.com>

Hi Dora,

You could move those two lines that sets the locale to en-US before the 
for-loop, so that if "args" contains -J-Duser.language/country then it 
can override the default en-US.

The JIRA issue needs noreg-self label.

Naoto

On 6/22/18 1:26 AM, Dora Zhou wrote:
> Hello,
> 
> Please help review the fix for JDK-8194152. Thank you.
> 
> The test compares output with expected error messages in English, set 
> locale to en-US so that the output are not translated into other languages.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8194152
> Webrev: http://cr.openjdk.java.net/~ljiang/8194152/webrev/ 
> <http://cr.openjdk.java.net/%7Eljiang/8194152/webrev/>
> 
> Regards,
> Dora

From dan.z.zhou at oracle.com  Mon Jun 25 07:04:16 2018
From: dan.z.zhou at oracle.com (Dora Zhou)
Date: Mon, 25 Jun 2018 15:04:16 +0800
Subject: <i18n dev> [11]RFR 8196213:
 sun/security/tools/jarsigner/warnings/NoTimestampTest.java test fails on
 ar_SA locale.
Message-ID: <915dfad2-a373-77f7-c5a0-38df52ca9e70@oracle.com>

Hello,

Please help review the fix for JDK-8196213. Thank you.
Set default locale to en-US so that the output display the date using 
Gregorian Calendar and Latn numbering system(0~9).

Bug: https://bugs.openjdk.java.net/browse/JDK-8196213
Webrev: http://cr.openjdk.java.net/~ljiang/8196213/webrev/ 
<http://cr.openjdk.java.net/%7Eljiang/8196213/webrev/>

Regards,
Dora


From dan.z.zhou at oracle.com  Mon Jun 25 07:37:39 2018
From: dan.z.zhou at oracle.com (Dora Zhou)
Date: Mon, 25 Jun 2018 15:37:39 +0800
Subject: <i18n dev> [11]RFR 8194152:
 sun/security/tools/jarsigner/AltProvider.java failed on de-DE locale
In-Reply-To: <ff9ad7a0-4f0b-414b-9cee-9a025a073750@default>
References: <ff9ad7a0-4f0b-414b-9cee-9a025a073750@default>
Message-ID: <44ed6c3a-4a19-fec3-edff-d9de27882c29@oracle.com>

Hi Naoto,

Thanks a lot for the review.
I have made suggested changes, Kindly have a look at: 
http://cr.openjdk.java.net/~ljiang/8194152/webrev.01/ 
<http://cr.openjdk.java.net/%7Eljiang/8194152/webrev.01/>

Regards,
Dora

> From: naoto.sato at oracle.com
> To: dan.z.zhou at oracle.com, i18n-dev at openjdk.java.net, core-libs-dev at openjdk.java.net, security-dev at openjdk.java.net
> Sent: Saturday, June 23, 2018 1:23:50 AM GMT +08:00 Beijing / Chongqing / Hong Kong / Urumqi
> Subject: Re: <i18n dev> [11]RFR 8194152: sun/security/tools/jarsigner/AltProvider.java failed on de-DE locale
>
> Hi Dora,
>
> You could move those two lines that sets the locale to en-US before the
> for-loop, so that if "args" contains -J-Duser.language/country then it
> can override the default en-US.
>
> The JIRA issue needs noreg-self label.
>
> Naoto
>
> On 6/22/18 1:26 AM, Dora Zhou wrote:
>> Hello,
>>
>> Please help review the fix for JDK-8194152. Thank you.
>>
>> The test compares output with expected error messages in English, set
>> locale to en-US so that the output are not translated into other languages.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8194152
>> Webrev: http://cr.openjdk.java.net/~ljiang/8194152/webrev/
>> <http://cr.openjdk.java.net/%7Eljiang/8194152/webrev/>
>>
>> Regards,
>> Dora


From naoto.sato at oracle.com  Mon Jun 25 16:03:55 2018
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 25 Jun 2018 09:03:55 -0700
Subject: <i18n dev> [11]RFR 8194152:
 sun/security/tools/jarsigner/AltProvider.java failed on de-DE locale
In-Reply-To: <44ed6c3a-4a19-fec3-edff-d9de27882c29@oracle.com>
References: <ff9ad7a0-4f0b-414b-9cee-9a025a073750@default>
 <44ed6c3a-4a19-fec3-edff-d9de27882c29@oracle.com>
Message-ID: <67097d88-8657-6bf2-8e45-3bdc52a2ffea@oracle.com>

Looks good.

Naoto

On 6/25/18 12:37 AM, Dora Zhou wrote:
> Hi Naoto,
> 
> Thanks a lot for the review.
> I have made suggested changes, Kindly have a look at: 
> http://cr.openjdk.java.net/~ljiang/8194152/webrev.01/ 
> <http://cr.openjdk.java.net/%7Eljiang/8194152/webrev.01/>
> 
> Regards,
> Dora
> 
>> From: naoto.sato at oracle.com
>> To: dan.z.zhou at oracle.com, i18n-dev at openjdk.java.net, 
>> core-libs-dev at openjdk.java.net, security-dev at openjdk.java.net
>> Sent: Saturday, June 23, 2018 1:23:50 AM GMT +08:00 Beijing / 
>> Chongqing / Hong Kong / Urumqi
>> Subject: Re: <i18n dev> [11]RFR 8194152: 
>> sun/security/tools/jarsigner/AltProvider.java failed on de-DE locale
>>
>> Hi Dora,
>>
>> You could move those two lines that sets the locale to en-US before the
>> for-loop, so that if "args" contains -J-Duser.language/country then it
>> can override the default en-US.
>>
>> The JIRA issue needs noreg-self label.
>>
>> Naoto
>>
>> On 6/22/18 1:26 AM, Dora Zhou wrote:
>>> Hello,
>>>
>>> Please help review the fix for JDK-8194152. Thank you.
>>>
>>> The test compares output with expected error messages in English, set
>>> locale to en-US so that the output are not translated into other 
>>> languages.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8194152
>>> Webrev: http://cr.openjdk.java.net/~ljiang/8194152/webrev/
>>> <http://cr.openjdk.java.net/%7Eljiang/8194152/webrev/>
>>>
>>> Regards,
>>> Dora
> 

From naoto.sato at oracle.com  Mon Jun 25 16:43:42 2018
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 25 Jun 2018 09:43:42 -0700
Subject: <i18n dev> [11]RFR 8196213:
 sun/security/tools/jarsigner/warnings/NoTimestampTest.java test fails on
 ar_SA locale.
In-Reply-To: <915dfad2-a373-77f7-c5a0-38df52ca9e70@oracle.com>
References: <915dfad2-a373-77f7-c5a0-38df52ca9e70@oracle.com>
Message-ID: <49bcf97c-0eec-4481-9114-918baa6b4f48@oracle.com>

Looks good.

Naoto

On 6/25/18 12:04 AM, Dora Zhou wrote:
> Hello,
> 
> Please help review the fix for JDK-8196213. Thank you.
> Set default locale to en-US so that the output display the date using 
> Gregorian Calendar and Latn numbering system(0~9).
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8196213
> Webrev: http://cr.openjdk.java.net/~ljiang/8196213/webrev/ 
> <http://cr.openjdk.java.net/%7Eljiang/8196213/webrev/>
> 
> Regards,
> Dora
> 

From TOSHIONA at jp.ibm.com  Tue Jun 26 08:46:28 2018
From: TOSHIONA at jp.ibm.com (Toshio 5 Nakamura)
Date: Tue, 26 Jun 2018 17:46:28 +0900
Subject: <i18n dev> Proposal: Input Method re-connection
Message-ID: <OFBB0768B9.10DBB2F3-ON002582B8.002F29E0-492582B8.00303313@notes.na.collabserv.com>


Hello,

I'd like to contribute a proposal about Input Method (IM) re-connection
on Linux. This is a part of contribution of IBM enhancements.

Issue:
After IM process (fcitx, kinput2, etc.) was down, Java GUI application
cannot use it even if IM process is restarted. This change try to
re-connect IM when its process was restarted on Linux.

Description of changes:
- XRegisterIMInstantiateCallback is set in DestroyXIMCallback.
- Saved the latest activated X11InputMethod instance and use it to
   call its activate method in the instantiate callback.
- XSelectInput in XMSelection.java may reset the
   XRegisterIMInstantiateCallback entry, so it's changed to keep the
   current registers.

Patch:
http://cr.openjdk.java.net/~aleonard/im_resume/webrev.00/
(I asked my colleague to store my patch for easy reference.
 I'm a contributor and need a sponsor of the proposal.)

Could I ask someone to kindly become a sponsor of this proposal?

Thanks,
Toshio Nakamura, IBM Japan

From takiguc at linux.vnet.ibm.com  Wed Jun 27 13:45:29 2018
From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi)
Date: Wed, 27 Jun 2018 22:45:29 +0900
Subject: <i18n dev> Proposal: Memory leak issue on awt_InputMethod.c
Message-ID: <e568e8afdb224c03de6d21a1f8814b00@linux.vnet.ibm.com>

Hello,

I should post this mail before starting JDK11 RDP1.

I found memory leak issue on awt_InputMethod.c.

See src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c.
On line 1117, memory area was allocated by malloc(), but free() is 
missing
===========================================
   1099          if (text->feedback != NULL) {
   1100              int cnt;
   1101              jint *tmpstyle;
   1102
   1103              style = (*env)->NewIntArray(env, text->length);
   1104              if (JNU_IsNull(env, style)) {
   1105                  (*env)->ExceptionClear(env);
   1106                  THROW_OUT_OF_MEMORY_ERROR();
   1107                  goto finally;
   1108              }
   1109
   1110              if (sizeof(XIMFeedback) == sizeof(jint)) {
   1111                  /*
   1112                   * Optimization to avoid copying the array
   1113                   */
   1114                  (*env)->SetIntArrayRegion(env, style, 0,
   1115                                            text->length, (jint 
*)text->feedback);
   1116              } else {
   1117                  tmpstyle  = (jint 
*)malloc(sizeof(jint)*(text->length));
   1118                  if (tmpstyle == (jint *) NULL) {
   1119                      THROW_OUT_OF_MEMORY_ERROR();
   1120                      goto finally;
   1121                  }
   1122                  for (cnt = 0; cnt < (int)text->length; cnt++)
   1123                          tmpstyle[cnt] = text->feedback[cnt];
   1124                  (*env)->SetIntArrayRegion(env, style, 0,
   1125                                            text->length, (jint 
*)tmpstyle);
   1126              }
   1127          }
===========================================
In my investigation, malloc() was called on RHEL7 x86_64 with Japanese 
Input Method.

I'd like to obtain a sponsor for this patch.
--------
--- old/src/java.desktop/aix/native/libawt_xawt/awt/awt_InputMethod.c    
2018-06-27 02:03:48.134991703 +0900
+++ new/src/java.desktop/aix/native/libawt_xawt/awt/awt_InputMethod.c    
2018-06-27 02:03:47.493005265 +0900
@@ -1148,6 +1148,7 @@
                          tmpstyle[cnt] = text->feedback[cnt];
                  (*env)->SetIntArrayRegion(env, style, 0,
                                            text->length, (jint 
*)tmpstyle);
+                free(tmpstyle);
              }
          }
      }
--- old/src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c   
  2018-06-27 02:03:49.040972563 +0900
+++ new/src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c   
  2018-06-27 02:03:48.391986274 +0900
@@ -1123,6 +1123,7 @@
                          tmpstyle[cnt] = text->feedback[cnt];
                  (*env)->SetIntArrayRegion(env, style, 0,
                                            text->length, (jint 
*)tmpstyle);
+                free(tmpstyle);
              }
          }
      }
--------

Thanks,
Ichiroh Takiguchi
IBM Japan, Ltd.


From philip.race at oracle.com  Wed Jun 27 21:06:53 2018
From: philip.race at oracle.com (Phil Race)
Date: Wed, 27 Jun 2018 14:06:53 -0700
Subject: <i18n dev> <AWT Dev> Proposal: Memory leak issue on
	awt_InputMethod.c
In-Reply-To: <e568e8afdb224c03de6d21a1f8814b00@linux.vnet.ibm.com>
References: <e568e8afdb224c03de6d21a1f8814b00@linux.vnet.ibm.com>
Message-ID: <e40d54b4-6eca-caa6-219c-5c802fe27863@oracle.com>



On 06/27/2018 06:45 AM, Ichiroh Takiguchi wrote:
> Hello,
>
> I should post this mail before starting JDK11 RDP1.

Already too too late for that, but although this looks like a bug - and 
the correct fix -
the bug has been there forever .. since JDK 1.2  in 1998 !
That makes it a 20 year old bug, so I don't think we need to treat it as 
urgent
for JDK 11.

-phil.

>
> I found memory leak issue on awt_InputMethod.c.
>
> See src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c.
> On line 1117, memory area was allocated by malloc(), but free() is 
> missing
> ===========================================
>   1099          if (text->feedback != NULL) {
>   1100              int cnt;
>   1101              jint *tmpstyle;
>   1102
>   1103              style = (*env)->NewIntArray(env, text->length);
>   1104              if (JNU_IsNull(env, style)) {
>   1105                  (*env)->ExceptionClear(env);
>   1106                  THROW_OUT_OF_MEMORY_ERROR();
>   1107                  goto finally;
>   1108              }
>   1109
>   1110              if (sizeof(XIMFeedback) == sizeof(jint)) {
>   1111                  /*
>   1112                   * Optimization to avoid copying the array
>   1113                   */
>   1114                  (*env)->SetIntArrayRegion(env, style, 0,
>   1115                                            text->length, (jint 
> *)text->feedback);
>   1116              } else {
>   1117                  tmpstyle  = (jint 
> *)malloc(sizeof(jint)*(text->length));
>   1118                  if (tmpstyle == (jint *) NULL) {
>   1119                      THROW_OUT_OF_MEMORY_ERROR();
>   1120                      goto finally;
>   1121                  }
>   1122                  for (cnt = 0; cnt < (int)text->length; cnt++)
>   1123                          tmpstyle[cnt] = text->feedback[cnt];
>   1124                  (*env)->SetIntArrayRegion(env, style, 0,
>   1125                                            text->length, (jint 
> *)tmpstyle);
>   1126              }
>   1127          }
> ===========================================
> In my investigation, malloc() was called on RHEL7 x86_64 with Japanese 
> Input Method.
>
> I'd like to obtain a sponsor for this patch.
> --------
> --- old/src/java.desktop/aix/native/libawt_xawt/awt/awt_InputMethod.c 
> 2018-06-27 02:03:48.134991703 +0900
> +++ new/src/java.desktop/aix/native/libawt_xawt/awt/awt_InputMethod.c 
> 2018-06-27 02:03:47.493005265 +0900
> @@ -1148,6 +1148,7 @@
>                          tmpstyle[cnt] = text->feedback[cnt];
>                  (*env)->SetIntArrayRegion(env, style, 0,
>                                            text->length, (jint 
> *)tmpstyle);
> +                free(tmpstyle);
>              }
>          }
>      }
> --- old/src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c 
>  2018-06-27 02:03:49.040972563 +0900
> +++ new/src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c 
>  2018-06-27 02:03:48.391986274 +0900
> @@ -1123,6 +1123,7 @@
>                          tmpstyle[cnt] = text->feedback[cnt];
>                  (*env)->SetIntArrayRegion(env, style, 0,
>                                            text->length, (jint 
> *)tmpstyle);
> +                free(tmpstyle);
>              }
>          }
>      }
> --------
>
> Thanks,
> Ichiroh Takiguchi
> IBM Japan, Ltd.
>


From dipak.kumar at oracle.com  Thu Jun 28 09:12:32 2018
From: dipak.kumar at oracle.com (Dipak Kumar)
Date: Thu, 28 Jun 2018 02:12:32 -0700 (PDT)
Subject: <i18n dev> [8u-backport] Review Request: 8202696 Remove exclusion
 range for phonetic chars in windows fontconfig.properties
Message-ID: <70d9b877-9ce4-4965-89cc-72703071cbb5@default>

Hi,

Please review below patch for 8u-backport:

Mian JBS bug: https://bugs.openjdk.java.net/browse/JDK-8202696 
Webrev for 8u-backport: http://cr.openjdk.java.net/~dkumar/8202696/8u-backport/webrev.00/ 
JDK-11 changeset - http://hg.openjdk.java.net/jdk/client/rev/b9456394d24f 

Patch from JDK-11 doesn't apply cleanly because of file name and file path differences.
Moreover there are some additional ranges added to font exclusion in JDK-11 config file.

JPRT and font related Jtreg tests are fine.

Thanks,
Dipak

From takiguc at linux.vnet.ibm.com  Thu Jun 28 13:13:55 2018
From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi)
Date: Thu, 28 Jun 2018 22:13:55 +0900
Subject: <i18n dev> <AWT Dev> Proposal: Memory leak issue on
	awt_InputMethod.c
In-Reply-To: <e40d54b4-6eca-caa6-219c-5c802fe27863@oracle.com>
References: <e568e8afdb224c03de6d21a1f8814b00@linux.vnet.ibm.com>
 <e40d54b4-6eca-caa6-219c-5c802fe27863@oracle.com>
Message-ID: <eec2e84fff7ef747cb4e80eadbcebedb@linux.vnet.ibm.com>

Hello.
In my investigation, this issue only happens on 64 bit build only...

On 2018-06-28 06:06, Phil Race wrote:
> On 06/27/2018 06:45 AM, Ichiroh Takiguchi wrote:
>> Hello,
>> 
>> I should post this mail before starting JDK11 RDP1.
> 
> Already too too late for that, but although this looks like a bug -
> and the correct fix -
> the bug has been there forever .. since JDK 1.2  in 1998 !
> That makes it a 20 year old bug, so I don't think we need to treat it 
> as urgent
> for JDK 11.
> 
> -phil.
> 
>> 
>> I found memory leak issue on awt_InputMethod.c.
>> 
>> See src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c.
>> On line 1117, memory area was allocated by malloc(), but free() is 
>> missing
>> ===========================================
>>   1099          if (text->feedback != NULL) {
>>   1100              int cnt;
>>   1101              jint *tmpstyle;
>>   1102
>>   1103              style = (*env)->NewIntArray(env, text->length);
>>   1104              if (JNU_IsNull(env, style)) {
>>   1105                  (*env)->ExceptionClear(env);
>>   1106                  THROW_OUT_OF_MEMORY_ERROR();
>>   1107                  goto finally;
>>   1108              }
>>   1109
>>   1110              if (sizeof(XIMFeedback) == sizeof(jint)) {
>>   1111                  /*
>>   1112                   * Optimization to avoid copying the array
>>   1113                   */
>>   1114                  (*env)->SetIntArrayRegion(env, style, 0,
>>   1115                                            text->length, (jint 
>> *)text->feedback);
>>   1116              } else {
>>   1117                  tmpstyle  = (jint 
>> *)malloc(sizeof(jint)*(text->length));
>>   1118                  if (tmpstyle == (jint *) NULL) {
>>   1119                      THROW_OUT_OF_MEMORY_ERROR();
>>   1120                      goto finally;
>>   1121                  }
>>   1122                  for (cnt = 0; cnt < (int)text->length; cnt++)
>>   1123                          tmpstyle[cnt] = text->feedback[cnt];
>>   1124                  (*env)->SetIntArrayRegion(env, style, 0,
>>   1125                                            text->length, (jint 
>> *)tmpstyle);
>>   1126              }
>>   1127          }
>> ===========================================
>> In my investigation, malloc() was called on RHEL7 x86_64 with Japanese 
>> Input Method.
>> 
>> I'd like to obtain a sponsor for this patch.
>> --------
>> --- old/src/java.desktop/aix/native/libawt_xawt/awt/awt_InputMethod.c 
>> 2018-06-27 02:03:48.134991703 +0900
>> +++ new/src/java.desktop/aix/native/libawt_xawt/awt/awt_InputMethod.c 
>> 2018-06-27 02:03:47.493005265 +0900
>> @@ -1148,6 +1148,7 @@
>>                          tmpstyle[cnt] = text->feedback[cnt];
>>                  (*env)->SetIntArrayRegion(env, style, 0,
>>                                            text->length, (jint 
>> *)tmpstyle);
>> +                free(tmpstyle);
>>              }
>>          }
>>      }
>> --- old/src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c 
>>  2018-06-27 02:03:49.040972563 +0900
>> +++ new/src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c 
>>  2018-06-27 02:03:48.391986274 +0900
>> @@ -1123,6 +1123,7 @@
>>                          tmpstyle[cnt] = text->feedback[cnt];
>>                  (*env)->SetIntArrayRegion(env, style, 0,
>>                                            text->length, (jint 
>> *)tmpstyle);
>> +                free(tmpstyle);
>>              }
>>          }
>>      }
>> --------
>> 
>> Thanks,
>> Ichiroh Takiguchi
>> IBM Japan, Ltd.
>>