From li.jiang at oracle.com  Wed Jan  2 06:06:25 2019
From: li.jiang at oracle.com (li.jiang at oracle.com)
Date: Wed, 2 Jan 2019 14:06:25 +0800
Subject: <i18n dev> UnicodeDecoder U+FFFE handling
In-Reply-To: <aa94d1e7d0226b62194fc9fd2a136439e9918f30.camel@unportant.info>
References: <aa94d1e7d0226b62194fc9fd2a136439e9918f30.camel@unportant.info>
Message-ID: <dc3804fa-3f0f-30c6-fd6b-d749c001ef88@oracle.com>

Sounds this request is reasonable since Unicode 7: do not consider the 
U+FFFE in the middle of stream as malformed.

FAQ about private use characters and non-characters. [1] 
http://www.unicode.org/faq/private_use.html

Q: Are noncharacters invalid in Unicode strings and UTFs?
A: Absolutely not. Noncharacters do not cause a Unicode string to be 
ill-formed in any UTF.

Q: So how should libraries and tools handle noncharacters?
A: Library APIs, components, and tool applications (such as low-level 
text editors) which handle all Unicode strings should also handle 
noncharacters. Often this means simple pass-through, the same way such 
an API or tool would handle a reserved unassigned code point.

Thanks
Leo

On 12/24/18 3:06 AM, Cl?ment MATHIEU wrote:
> Hi,
> 
> I am wondering if UnicodeDecoder handling of U+FFFE is compliant with
> current Unicode specification. Supsicious code is:
> 
>         if (c == REVERSED_MARK) {
>              // A reversed BOM cannot occur within middle of stream
>              return CoderResult.malformedForLength(2);
>         }
> 
> Up to Unicode 6.3 Unicode specification said that U+FFFE is a non
> character and that non characters "should never been interchanged".
> Returning CR_MALFORMED on U+FFFE appears to be correct for Java 8
> (Unicode 6.2).
> 
> However, Unicode 7 changed that and now says:
> 
>        Applications are free to use any of these noncharacter code
>        points internally. They have no standard interpretation when
>        exchanged outside the context of internal use. However, they are
>        not illegal in interchange, nor does their presence cause Unicode
>        text to be ill-formed. [...] They are not prohibited from
>        occurring  in  valid  Unicode  strings  which  happen  to  be  in
>        terchanged. [...]. If a noncharacter is received in open
>        interchange, an application is not required to interpret it in
>        any way. It is good practice, however, to recognize it as a
>        noncharacter and to take appropriate action, such as replacing it
>        with U+FFFD replacement character, to indicate
>        the  problem  in  the  text.  It  is  not  recommended  to  simpl
>        y  delete  noncharacter  code points from such text, because of
>        the potential security issues caused by deleting uninterpreted
>        characters.
> 
> See:
>   - http://www.unicode.org/versions/corrigendum9.html
>   - https://www.unicode.org/versions/Unicode11.0.0/ch23.pdf (23.7)
> 
> Do you think that returning CR_MALFORMED is still OK?
> 
> Regards,
> Cl?ment MATHIEU
> 

From naoto.sato at oracle.com  Thu Jan  3 16:56:10 2019
From: naoto.sato at oracle.com (Naoto Sato)
Date: Thu, 3 Jan 2019 08:56:10 -0800
Subject: <i18n dev> [12] RFR: 8215303: Allowing additional currency code
 points from later Unicode updates
Message-ID: <b906c7e0-0dd7-ee5a-af09-c680cbf4bc5b@oracle.com>

Hello,

Please review the fix to the following issue (and its approved CSR):

https://bugs.openjdk.java.net/browse/JDK-8215303
https://bugs.openjdk.java.net/browse/JDK-8215305

The proposed changeset is located at:

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

This is a spec only modification that will allow future code point 
additions to the Unicode currency symbols block without any spec 
changes. This is especially important for update releases (such as 8u) 
without releasing a Maintenance Release.

Naoto

From naoto.sato at oracle.com  Thu Jan  3 21:06:47 2019
From: naoto.sato at oracle.com (Naoto Sato)
Date: Thu, 3 Jan 2019 13:06:47 -0800
Subject: <i18n dev> UnicodeDecoder U+FFFE handling
In-Reply-To: <dc3804fa-3f0f-30c6-fd6b-d749c001ef88@oracle.com>
References: <aa94d1e7d0226b62194fc9fd2a136439e9918f30.camel@unportant.info>
 <dc3804fa-3f0f-30c6-fd6b-d749c001ef88@oracle.com>
Message-ID: <eb4b6783-5069-13a1-a4f7-448feb7831f6@oracle.com>

Sounds reasonable. Filed the following issue:

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

Naoto

On 1/1/19 10:06 PM, li.jiang at oracle.com wrote:
> Sounds this request is reasonable since Unicode 7: do not consider the 
> U+FFFE in the middle of stream as malformed.
> 
> FAQ about private use characters and non-characters. [1] 
> http://www.unicode.org/faq/private_use.html
> 
> Q: Are noncharacters invalid in Unicode strings and UTFs?
> A: Absolutely not. Noncharacters do not cause a Unicode string to be 
> ill-formed in any UTF.
> 
> Q: So how should libraries and tools handle noncharacters?
> A: Library APIs, components, and tool applications (such as low-level 
> text editors) which handle all Unicode strings should also handle 
> noncharacters. Often this means simple pass-through, the same way such 
> an API or tool would handle a reserved unassigned code point.
> 
> Thanks
> Leo
> 
> On 12/24/18 3:06 AM, Cl?ment MATHIEU wrote:
>> Hi,
>>
>> I am wondering if UnicodeDecoder handling of U+FFFE is compliant with
>> current Unicode specification. Supsicious code is:
>>
>> ??????? if (c == REVERSED_MARK) {
>> ???????????? // A reversed BOM cannot occur within middle of stream
>> ???????????? return CoderResult.malformedForLength(2);
>> ??????? }
>>
>> Up to Unicode 6.3 Unicode specification said that U+FFFE is a non
>> character and that non characters "should never been interchanged".
>> Returning CR_MALFORMED on U+FFFE appears to be correct for Java 8
>> (Unicode 6.2).
>>
>> However, Unicode 7 changed that and now says:
>>
>> ?????? Applications are free to use any of these noncharacter code
>> ?????? points internally. They have no standard interpretation when
>> ?????? exchanged outside the context of internal use. However, they are
>> ?????? not illegal in interchange, nor does their presence cause Unicode
>> ?????? text to be ill-formed. [...] They are not prohibited from
>> ?????? occurring? in? valid? Unicode? strings? which? happen? to? be? in
>> ?????? terchanged. [...]. If a noncharacter is received in open
>> ?????? interchange, an application is not required to interpret it in
>> ?????? any way. It is good practice, however, to recognize it as a
>> ?????? noncharacter and to take appropriate action, such as replacing it
>> ?????? with U+FFFD replacement character, to indicate
>> ?????? the? problem? in? the? text.? It? is? not? recommended? to? simpl
>> ?????? y? delete? noncharacter? code points from such text, because of
>> ?????? the potential security issues caused by deleting uninterpreted
>> ?????? characters.
>>
>> See:
>> ? - http://www.unicode.org/versions/corrigendum9.html
>> ? - https://www.unicode.org/versions/Unicode11.0.0/ch23.pdf (23.7)
>>
>> Do you think that returning CR_MALFORMED is still OK?
>>
>> Regards,
>> Cl?ment MATHIEU
>>

From dan.z.zhou at oracle.com  Fri Jan  4 02:28:09 2019
From: dan.z.zhou at oracle.com (Dora Zhou)
Date: Fri, 4 Jan 2019 10:28:09 +0800
Subject: <i18n dev> [13] RFR 8215913:
 [Test_bug]java/util/Locale/LocaleProvidersRun.java failed on de_DE and
 ja_JP locale.
Message-ID: <d57e3973-8a1c-aa7f-1621-92717ffe4b48@oracle.com>

Hello,

Please help review the fix for the test bug 
java/util/Locale/LocaleProvidersRun.java failed on de_DE and ja_JP locale.

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

Webrev: http://cr.openjdk.java.net/~dzhou/8215913/webrev.00/

Thanks,
Dora


From rachna.goel at oracle.com  Fri Jan  4 09:44:38 2019
From: rachna.goel at oracle.com (Rachna Goel)
Date: Fri, 4 Jan 2019 15:14:38 +0530
Subject: <i18n dev> [13] RFR 8215913:
 [Test_bug]java/util/Locale/LocaleProvidersRun.java failed on de_DE and
 ja_JP locale.
In-Reply-To: <d57e3973-8a1c-aa7f-1621-92717ffe4b48@oracle.com>
References: <d57e3973-8a1c-aa7f-1621-92717ffe4b48@oracle.com>
Message-ID: <3e91eea6-513b-2858-c041-55de064bb5fa@oracle.com>

Hi Dora,

Kindly update copyright years in both files and add bug id in 
LocaleProvidersRun.java.

Other than that, it looks good to me.

Thanks,

Rachna


On 1/4/19 7:58 AM, Dora Zhou wrote:
> Hello,
>
> Please help review the fix for the test bug 
> java/util/Locale/LocaleProvidersRun.java failed on de_DE and ja_JP 
> locale.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8215913
>
> Webrev: http://cr.openjdk.java.net/~dzhou/8215913/webrev.00/
>
> Thanks,
> Dora
>

-- 
Thanks,
Rachna


From rachna.goel at oracle.com  Fri Jan  4 10:22:09 2019
From: rachna.goel at oracle.com (Rachna Goel)
Date: Fri, 4 Jan 2019 15:52:09 +0530
Subject: <i18n dev> [12] RFR: 8215303: Allowing additional currency code
 points from later Unicode updates
In-Reply-To: <b906c7e0-0dd7-ee5a-af09-c680cbf4bc5b@oracle.com>
References: <b906c7e0-0dd7-ee5a-af09-c680cbf4bc5b@oracle.com>
Message-ID: <9f1daecc-0000-bcbe-5055-2510de27f4a2@oracle.com>

Hi Naoto,

Your fix looks good to me.

Thanks,

Rachna

On 1/3/19 10:26 PM, Naoto Sato wrote:
> Hello,
>
> Please review the fix to the following issue (and its approved CSR):
>
> https://bugs.openjdk.java.net/browse/JDK-8215303
> https://bugs.openjdk.java.net/browse/JDK-8215305
>
> The proposed changeset is located at:
>
> http://cr.openjdk.java.net/~naoto/8215303/webrev.00/
>
> This is a spec only modification that will allow future code point 
> additions to the Unicode currency symbols block without any spec 
> changes. This is especially important for update releases (such as 8u) 
> without releasing a Maintenance Release.
>
> Naoto

-- 
Thanks,
Rachna


From rachna.goel at oracle.com  Fri Jan  4 10:24:42 2019
From: rachna.goel at oracle.com (Rachna Goel)
Date: Fri, 4 Jan 2019 15:54:42 +0530
Subject: <i18n dev> [12] RFR: 8215303: Allowing additional currency code
 points from later Unicode updates
In-Reply-To: <b906c7e0-0dd7-ee5a-af09-c680cbf4bc5b@oracle.com>
References: <b906c7e0-0dd7-ee5a-af09-c680cbf4bc5b@oracle.com>
Message-ID: <bec20710-7b22-88fa-dd16-ed6b20a9451a@oracle.com>

Hi Naoto,

just one nit, copyright year need to be updated in Character.java.

Thanks,

Rachna


On 1/3/19 10:26 PM, Naoto Sato wrote:
> Hello,
>
> Please review the fix to the following issue (and its approved CSR):
>
> https://bugs.openjdk.java.net/browse/JDK-8215303
> https://bugs.openjdk.java.net/browse/JDK-8215305
>
> The proposed changeset is located at:
>
> http://cr.openjdk.java.net/~naoto/8215303/webrev.00/
>
> This is a spec only modification that will allow future code point 
> additions to the Unicode currency symbols block without any spec 
> changes. This is especially important for update releases (such as 8u) 
> without releasing a Maintenance Release.
>
> Naoto

-- 
Thanks,
Rachna


From nishit.jain at oracle.com  Fri Jan  4 10:28:12 2019
From: nishit.jain at oracle.com (Nishit Jain)
Date: Fri, 4 Jan 2019 15:58:12 +0530
Subject: <i18n dev> [12] RFR: 8215303: Allowing additional currency code
 points from later Unicode updates
In-Reply-To: <b906c7e0-0dd7-ee5a-af09-c680cbf4bc5b@oracle.com>
References: <b906c7e0-0dd7-ee5a-af09-c680cbf4bc5b@oracle.com>
Message-ID: <65abc1b3-adc7-48ce-619d-8264a8c01472@oracle.com>

Changes looks fine to me.

Regards,
Nishit Jain
On 03-01-2019 22:26, Naoto Sato wrote:
> Hello,
>
> Please review the fix to the following issue (and its approved CSR):
>
> https://bugs.openjdk.java.net/browse/JDK-8215303
> https://bugs.openjdk.java.net/browse/JDK-8215305
>
> The proposed changeset is located at:
>
> http://cr.openjdk.java.net/~naoto/8215303/webrev.00/
>
> This is a spec only modification that will allow future code point 
> additions to the Unicode currency symbols block without any spec 
> changes. This is especially important for update releases (such as 8u) 
> without releasing a Maintenance Release.
>
> Naoto


From chris.hegarty at oracle.com  Fri Jan  4 14:13:42 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 4 Jan 2019 14:13:42 +0000
Subject: <i18n dev> [12] RFR: 8215303: Allowing additional currency code
 points from later Unicode updates
In-Reply-To: <9f1daecc-0000-bcbe-5055-2510de27f4a2@oracle.com>
References: <b906c7e0-0dd7-ee5a-af09-c680cbf4bc5b@oracle.com>
 <9f1daecc-0000-bcbe-5055-2510de27f4a2@oracle.com>
Message-ID: <715CFBF2-E35C-43D2-A9DB-F56BA220D899@oracle.com>



On 1/3/19 10:26 PM, Naoto Sato wrote:
> Hello,
> 
> Please review the fix to the following issue (and its approved CSR):
> 
> https://bugs.openjdk.java.net/browse/JDK-8215303
> https://bugs.openjdk.java.net/browse/JDK-8215305
> 
> The proposed changeset is located at:
> 
> http://cr.openjdk.java.net/~naoto/8215303/webrev.00/

I think this is a positive change, but for clarity ( since I cannot find it
in the CSR ), will this change have an impact on the set of allowable
characters that can be used as identifiers, i.e. isJavaIdentifierStart,
isJavaIdentifierPart?

-Chris.




From naoto.sato at oracle.com  Fri Jan  4 17:10:38 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Fri, 4 Jan 2019 09:10:38 -0800
Subject: <i18n dev> [12] RFR: 8215303: Allowing additional currency code
 points from later Unicode updates
In-Reply-To: <715CFBF2-E35C-43D2-A9DB-F56BA220D899@oracle.com>
References: <b906c7e0-0dd7-ee5a-af09-c680cbf4bc5b@oracle.com>
 <9f1daecc-0000-bcbe-5055-2510de27f4a2@oracle.com>
 <715CFBF2-E35C-43D2-A9DB-F56BA220D899@oracle.com>
Message-ID: <d5463b2f-9638-2d1b-9f82-c6105d58bd5c@oracle.com>

Hi Chris,

Yes, it will affect the behavior of those methods. This has been 
discussed within the JLS folks, and their understanding was that the 
risk is minimal and OK to proceed. I was not involved in the discussion, 
but here are the reasons I can think of.

- The Currency Symbols range is very limited (U+20A0-U+20CF)
- The change is to allow the code point, not the way around, so existing 
identifiers are guaranteed to work.
- Apart from this CSR, this kind of behavior change is common when a 
Unicode upgrade is done.

Naoto

On 1/4/19 6:13 AM, Chris Hegarty wrote:
> 
> 
> On 1/3/19 10:26 PM, Naoto Sato wrote:
>> Hello,
>>
>> Please review the fix to the following issue (and its approved CSR):
>>
>> https://bugs.openjdk.java.net/browse/JDK-8215303
>> https://bugs.openjdk.java.net/browse/JDK-8215305
>>
>> The proposed changeset is located at:
>>
>> http://cr.openjdk.java.net/~naoto/8215303/webrev.00/
> 
> I think this is a positive change, but for clarity ( since I cannot find it
> in the CSR ), will this change have an impact on the set of allowable
> characters that can be used as identifiers, i.e. isJavaIdentifierStart,
> isJavaIdentifierPart?
> 
> -Chris.
> 
> 
> 

From chris.hegarty at oracle.com  Fri Jan  4 17:18:42 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 4 Jan 2019 17:18:42 +0000
Subject: <i18n dev> [12] RFR: 8215303: Allowing additional currency code
 points from later Unicode updates
In-Reply-To: <d5463b2f-9638-2d1b-9f82-c6105d58bd5c@oracle.com>
References: <b906c7e0-0dd7-ee5a-af09-c680cbf4bc5b@oracle.com>
 <9f1daecc-0000-bcbe-5055-2510de27f4a2@oracle.com>
 <715CFBF2-E35C-43D2-A9DB-F56BA220D899@oracle.com>
 <d5463b2f-9638-2d1b-9f82-c6105d58bd5c@oracle.com>
Message-ID: <B05E56FB-43AD-4F87-9A7C-7F016FC9725C@oracle.com>

Thanks Naoto.

> On 4 Jan 2019, at 17:10, naoto.sato at oracle.com wrote:
> 
> Hi Chris,
> 
> Yes, it will affect the behavior of those methods. This has been discussed within the JLS folks, and their understanding was that the risk is minimal and OK to proceed. I was not involved in the discussion, but here are the reasons I can think of.

Ok. Should the CSR be updated to indicate this?

> - The Currency Symbols range is very limited (U+20A0-U+20CF)
> - The change is to allow the code point, not the way around, so existing identifiers are guaranteed to work.
> - Apart from this CSR, this kind of behavior change is common when a Unicode upgrade is done.

Sure, all good and valid reasons.

Will compilations with `--release N-1` wind back the set of allowable 
identifiers?  It possibly should, if so how does one do similar when/if
the set of currency characters is expanded in an update release?

-Chris.

> Naoto
> 
> On 1/4/19 6:13 AM, Chris Hegarty wrote:
>> On 1/3/19 10:26 PM, Naoto Sato wrote:
>>> Hello,
>>> 
>>> Please review the fix to the following issue (and its approved CSR):
>>> 
>>> https://bugs.openjdk.java.net/browse/JDK-8215303
>>> https://bugs.openjdk.java.net/browse/JDK-8215305
>>> 
>>> The proposed changeset is located at:
>>> 
>>> http://cr.openjdk.java.net/~naoto/8215303/webrev.00/
>> I think this is a positive change, but for clarity ( since I cannot find it
>> in the CSR ), will this change have an impact on the set of allowable
>> characters that can be used as identifiers, i.e. isJavaIdentifierStart,
>> isJavaIdentifierPart?
>> -Chris.


From naoto.sato at oracle.com  Fri Jan  4 17:43:37 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Fri, 4 Jan 2019 09:43:37 -0800
Subject: <i18n dev> [12] RFR: 8215303: Allowing additional currency code
 points from later Unicode updates
In-Reply-To: <bec20710-7b22-88fa-dd16-ed6b20a9451a@oracle.com>
References: <b906c7e0-0dd7-ee5a-af09-c680cbf4bc5b@oracle.com>
 <bec20710-7b22-88fa-dd16-ed6b20a9451a@oracle.com>
Message-ID: <892612da-1663-6dfe-ef95-a17ac3513bbe@oracle.com>

Hi Rachna,

Updated: http://cr.openjdk.java.net/~naoto/8215303/webrev.01/

Naoto

On 1/4/19 2:24 AM, Rachna Goel wrote:
> Hi Naoto,
> 
> just one nit, copyright year need to be updated in Character.java.
> 
> Thanks,
> 
> Rachna
> 
> 
> On 1/3/19 10:26 PM, Naoto Sato wrote:
>> Hello,
>>
>> Please review the fix to the following issue (and its approved CSR):
>>
>> https://bugs.openjdk.java.net/browse/JDK-8215303
>> https://bugs.openjdk.java.net/browse/JDK-8215305
>>
>> The proposed changeset is located at:
>>
>> http://cr.openjdk.java.net/~naoto/8215303/webrev.00/
>>
>> This is a spec only modification that will allow future code point 
>> additions to the Unicode currency symbols block without any spec 
>> changes. This is especially important for update releases (such as 8u) 
>> without releasing a Maintenance Release.
>>
>> Naoto
> 
> -- 
> Thanks,
> Rachna
> 

From naoto.sato at oracle.com  Fri Jan  4 17:53:53 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Fri, 4 Jan 2019 09:53:53 -0800
Subject: <i18n dev> [12] RFR: 8215303: Allowing additional currency code
 points from later Unicode updates
In-Reply-To: <B05E56FB-43AD-4F87-9A7C-7F016FC9725C@oracle.com>
References: <b906c7e0-0dd7-ee5a-af09-c680cbf4bc5b@oracle.com>
 <9f1daecc-0000-bcbe-5055-2510de27f4a2@oracle.com>
 <715CFBF2-E35C-43D2-A9DB-F56BA220D899@oracle.com>
 <d5463b2f-9638-2d1b-9f82-c6105d58bd5c@oracle.com>
 <B05E56FB-43AD-4F87-9A7C-7F016FC9725C@oracle.com>
Message-ID: <5a3e575e-a698-ad79-8b5f-a0337a1b8f72@oracle.com>

Hi Chris,

Yes. I just updated the CSR, adding the description in the compatibility 
risk:

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

Naoto

On 1/4/19 9:18 AM, Chris Hegarty wrote:
> Thanks Naoto.
> 
>> On 4 Jan 2019, at 17:10, naoto.sato at oracle.com wrote:
>>
>> Hi Chris,
>>
>> Yes, it will affect the behavior of those methods. This has been discussed within the JLS folks, and their understanding was that the risk is minimal and OK to proceed. I was not involved in the discussion, but here are the reasons I can think of.
> 
> Ok. Should the CSR be updated to indicate this?
> 
>> - The Currency Symbols range is very limited (U+20A0-U+20CF)
>> - The change is to allow the code point, not the way around, so existing identifiers are guaranteed to work.
>> - Apart from this CSR, this kind of behavior change is common when a Unicode upgrade is done.
> 
> Sure, all good and valid reasons.
> 
> Will compilations with `--release N-1` wind back the set of allowable
> identifiers?  It possibly should, if so how does one do similar when/if
> the set of currency characters is expanded in an update release?
> 
> -Chris.
> 
>> Naoto
>>
>> On 1/4/19 6:13 AM, Chris Hegarty wrote:
>>> On 1/3/19 10:26 PM, Naoto Sato wrote:
>>>> Hello,
>>>>
>>>> Please review the fix to the following issue (and its approved CSR):
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8215303
>>>> https://bugs.openjdk.java.net/browse/JDK-8215305
>>>>
>>>> The proposed changeset is located at:
>>>>
>>>> http://cr.openjdk.java.net/~naoto/8215303/webrev.00/
>>> I think this is a positive change, but for clarity ( since I cannot find it
>>> in the CSR ), will this change have an impact on the set of allowable
>>> characters that can be used as identifiers, i.e. isJavaIdentifierStart,
>>> isJavaIdentifierPart?
>>> -Chris.
> 

From Alan.Bateman at oracle.com  Sat Jan  5 17:03:15 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 5 Jan 2019 17:03:15 +0000
Subject: <i18n dev> [12] RFR: 8215303: Allowing additional currency code
 points from later Unicode updates
In-Reply-To: <B05E56FB-43AD-4F87-9A7C-7F016FC9725C@oracle.com>
References: <b906c7e0-0dd7-ee5a-af09-c680cbf4bc5b@oracle.com>
 <9f1daecc-0000-bcbe-5055-2510de27f4a2@oracle.com>
 <715CFBF2-E35C-43D2-A9DB-F56BA220D899@oracle.com>
 <d5463b2f-9638-2d1b-9f82-c6105d58bd5c@oracle.com>
 <B05E56FB-43AD-4F87-9A7C-7F016FC9725C@oracle.com>
Message-ID: <8f889443-990f-bf3c-cc8d-303c41d1ce25@oracle.com>

On 04/01/2019 17:18, Chris Hegarty wrote:
> Will compilations with `--release N-1` wind back the set of allowable
> identifiers?  It possibly should, if so how does one do similar when/if
> the set of currency characters is expanded in an update release?
>
I don't think `javac --release` takes the Unicode version into account. 
Using JDK 11 javac, I can compile the following with `--release 8` and 
it will compile even though the Bitcoin currency symbol was only added 
in Unicode 10 and Java SE 11. It won't compile with JDK 10 or older of 
course.

class X {
 ?? double ? = 0.0;
}

I agree with your comment that the CSR could be be expanded to at least 
make it clear that if support for a currency symbol is added in some 
future update of JDK N then source code using it in identifiers will 
compile with the JDK update that supports the symbol, not by the GA or 
previous updates of JDK N.

-Alan

From dan.z.zhou at oracle.com  Mon Jan  7 07:06:07 2019
From: dan.z.zhou at oracle.com (Dora Zhou)
Date: Mon, 7 Jan 2019 15:06:07 +0800
Subject: <i18n dev> [13] RFR 8215913:
 [Test_bug]java/util/Locale/LocaleProvidersRun.java failed on de_DE and
 ja_JP locale.
In-Reply-To: <3e91eea6-513b-2858-c041-55de064bb5fa@oracle.com>
References: <d57e3973-8a1c-aa7f-1621-92717ffe4b48@oracle.com>
 <3e91eea6-513b-2858-c041-55de064bb5fa@oracle.com>
Message-ID: <bb6f7057-e6ca-a536-82da-aa5eef6c76c7@oracle.com>

Hi Rachna,

Updated the webrev: http://cr.openjdk.java.net/~dzhou/8215913/webrev.01/

Regards,
Dora
On 2019/1/4 17:44, Rachna Goel wrote:
>
> Hi Dora,
>
> Kindly update copyright years in both files and add bug id in 
> LocaleProvidersRun.java.
>
> Other than that, it looks good to me.
>
> Thanks,
>
> Rachna
>
>
> On 1/4/19 7:58 AM, Dora Zhou wrote:
>> Hello,
>>
>> Please help review the fix for the test bug 
>> java/util/Locale/LocaleProvidersRun.java failed on de_DE and ja_JP 
>> locale.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8215913
>>
>> Webrev: http://cr.openjdk.java.net/~dzhou/8215913/webrev.00/
>>
>> Thanks,
>> Dora
>>
>
> -- 
> Thanks,
> Rachna

From chris.hegarty at oracle.com  Mon Jan  7 10:11:38 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 7 Jan 2019 10:11:38 +0000
Subject: <i18n dev> [12] RFR: 8215303: Allowing additional currency code
 points from later Unicode updates
In-Reply-To: <8f889443-990f-bf3c-cc8d-303c41d1ce25@oracle.com>
References: <b906c7e0-0dd7-ee5a-af09-c680cbf4bc5b@oracle.com>
 <9f1daecc-0000-bcbe-5055-2510de27f4a2@oracle.com>
 <715CFBF2-E35C-43D2-A9DB-F56BA220D899@oracle.com>
 <d5463b2f-9638-2d1b-9f82-c6105d58bd5c@oracle.com>
 <B05E56FB-43AD-4F87-9A7C-7F016FC9725C@oracle.com>
 <8f889443-990f-bf3c-cc8d-303c41d1ce25@oracle.com>
Message-ID: <13667920-B8E8-4DC9-8D0F-06FEFE76CB57@oracle.com>


> On 5 Jan 2019, at 17:03, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 04/01/2019 17:18, Chris Hegarty wrote:
>> Will compilations with `--release N-1` wind back the set of allowable
>> identifiers?  It possibly should, if so how does one do similar when/if
>> the set of currency characters is expanded in an update release?
>> 
> I don't think `javac --release` takes the Unicode version into account. 

That is a bug.

> I agree with your comment that the CSR could be be expanded to at least make it clear that if support for a currency symbol is added in some future update of JDK N then source code using it in identifiers will compile with the JDK update that supports the symbol, not by the GA or previous updates of JDK N.


The question is whether, or not, it is reasonable to allow ( part of )
the set of Java identifiers, in the language, to be an implementation
detail? If so, then certain code compiled and run on BuzzCorps Java
implementation may not compile or run on WollyInc's Java implementation.
( Both are compliant Java SE implementations )

I accept that the set of implementation specific currency characters
may noy be all that large, but this does seem like a significant 
change, and I want to ensure that the implications are fully understood.

-Chris.

From rachna.goel at oracle.com  Mon Jan  7 10:29:28 2019
From: rachna.goel at oracle.com (Rachna Goel)
Date: Mon, 7 Jan 2019 15:59:28 +0530
Subject: <i18n dev> [13] RFR 8215913:
 [Test_bug]java/util/Locale/LocaleProvidersRun.java failed on de_DE and
 ja_JP locale.
In-Reply-To: <bb6f7057-e6ca-a536-82da-aa5eef6c76c7@oracle.com>
References: <d57e3973-8a1c-aa7f-1621-92717ffe4b48@oracle.com>
 <3e91eea6-513b-2858-c041-55de064bb5fa@oracle.com>
 <bb6f7057-e6ca-a536-82da-aa5eef6c76c7@oracle.com>
Message-ID: <27e5a10a-2e52-bb11-11b0-8e3d235847f5@oracle.com>

Looks good to me.

Thanks,
Rachna
On 1/7/19 12:36 PM, Dora Zhou wrote:
>
> Hi Rachna,
>
> Updated the webrev: http://cr.openjdk.java.net/~dzhou/8215913/webrev.01/
>
> Regards,
> Dora
> On 2019/1/4 17:44, Rachna Goel wrote:
>>
>> Hi Dora,
>>
>> Kindly update copyright years in both files and add bug id in 
>> LocaleProvidersRun.java.
>>
>> Other than that, it looks good to me.
>>
>> Thanks,
>>
>> Rachna
>>
>>
>> On 1/4/19 7:58 AM, Dora Zhou wrote:
>>> Hello,
>>>
>>> Please help review the fix for the test bug 
>>> java/util/Locale/LocaleProvidersRun.java failed on de_DE and ja_JP 
>>> locale.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8215913
>>>
>>> Webrev: http://cr.openjdk.java.net/~dzhou/8215913/webrev.00/
>>>
>>> Thanks,
>>> Dora
>>>
>>
>> -- 
>> Thanks,
>> Rachna

-- 
Thanks,
Rachna


From yamadamn at gmail.com  Mon Jan  7 13:36:50 2019
From: yamadamn at gmail.com (Takahiro YAMADA)
Date: Mon, 7 Jan 2019 22:36:50 +0900
Subject: <i18n dev> Wrong SimpleDateFormat behavior with Japanese Imperial
	Calendar
Message-ID: <CANtCpJChCUPxMSmZzsMZXFWwCsedE87S2gTjkg519K_SrDusyg@mail.gmail.com>

Hi,

I filed a bug of SimpleDateFormat through
https://bugreport.java.com/bugreport/ .
And, it is registered as JDK-8216204 (
https://bugs.openjdk.java.net/browse/JDK-8216204).

At first, the assignee misunderstood my intention, and the issue once
closed with "Not an issue" status.
Shinya, aka Japanese youngest committer, has helped; so it's reopened.
Japan is still in the Heisei era, and I'd like to format the initial "H";
but Java 9 and later (through 13-ea) can't print "H" by SimpleDateFormat.

Could you follow and resolve this issue?

--
Takahiro YAMADA

From yamadamn at gmail.com  Mon Jan  7 13:45:36 2019
From: yamadamn at gmail.com (Takahiro YAMADA)
Date: Mon, 7 Jan 2019 22:45:36 +0900
Subject: <i18n dev> Wrong SimpleDateFormat behavior with Japanese
	Imperial Calendar
In-Reply-To: <CANtCpJChCUPxMSmZzsMZXFWwCsedE87S2gTjkg519K_SrDusyg@mail.gmail.com>
References: <CANtCpJChCUPxMSmZzsMZXFWwCsedE87S2gTjkg519K_SrDusyg@mail.gmail.com>
Message-ID: <CANtCpJAJzOuNxkc+RQdhhipAW6WZ9qyn5=ZRFLjVOV-TwbBJrQ@mail.gmail.com>

Hi,

The assignee Pallavi has already given a solution.
I understand the behavior is based on Java 9 onwards.
Sorry for my misunderstanding.


2019?1?7?(?) 22:38 Takahiro YAMADA <yamadamn at gmail.com>:

> Hi,
>
> I filed a bug of SimpleDateFormat through
> https://bugreport.java.com/bugreport/ .
> And, it is registered as JDK-8216204 (
> https://bugs.openjdk.java.net/browse/JDK-8216204).
>
> At first, the assignee misunderstood my intention, and the issue once
> closed with "Not an issue" status.
> Shinya, aka Japanese youngest committer, has helped; so it's reopened.
> Japan is still in the Heisei era, and I'd like to format the initial "H";
> but Java 9 and later (through 13-ea) can't print "H" by SimpleDateFormat.
>
> Could you follow and resolve this issue?
>
> --
> Takahiro YAMADA
>

From naoto.sato at oracle.com  Mon Jan  7 16:26:12 2019
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 7 Jan 2019 08:26:12 -0800
Subject: <i18n dev> [12] RFR: 8215303: Allowing additional currency code
 points from later Unicode updates
In-Reply-To: <13667920-B8E8-4DC9-8D0F-06FEFE76CB57@oracle.com>
References: <b906c7e0-0dd7-ee5a-af09-c680cbf4bc5b@oracle.com>
 <9f1daecc-0000-bcbe-5055-2510de27f4a2@oracle.com>
 <715CFBF2-E35C-43D2-A9DB-F56BA220D899@oracle.com>
 <d5463b2f-9638-2d1b-9f82-c6105d58bd5c@oracle.com>
 <B05E56FB-43AD-4F87-9A7C-7F016FC9725C@oracle.com>
 <8f889443-990f-bf3c-cc8d-303c41d1ce25@oracle.com>
 <13667920-B8E8-4DC9-8D0F-06FEFE76CB57@oracle.com>
Message-ID: <dbb9d7db-3ae3-f3b9-b857-9b78980ceaff@oracle.com>

Hi Chris,

On 1/7/19 2:11 AM, Chris Hegarty wrote:
> 
>> On 5 Jan 2019, at 17:03, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>>
>> On 04/01/2019 17:18, Chris Hegarty wrote:
>>> Will compilations with `--release N-1` wind back the set of allowable
>>> identifiers?  It possibly should, if so how does one do similar when/if
>>> the set of currency characters is expanded in an update release?
>>>
>> I don't think `javac --release` takes the Unicode version into account.
> 
> That is a bug.

Yes.

> 
>> I agree with your comment that the CSR could be be expanded to at least make it clear that if support for a currency symbol is added in some future update of JDK N then source code using it in identifiers will compile with the JDK update that supports the symbol, not by the GA or previous updates of JDK N.
> 
> 
> The question is whether, or not, it is reasonable to allow ( part of )
> the set of Java identifiers, in the language, to be an implementation
> detail? If so, then certain code compiled and run on BuzzCorps Java
> implementation may not compile or run on WollyInc's Java implementation.
> ( Both are compliant Java SE implementations )
> 
> I accept that the set of implementation specific currency characters
> may noy be all that large, but this does seem like a significant
> change, and I want to ensure that the implications are fully understood.

Agree. It's good to have more insights here. I will need to wait for 
someone more appropriate to answer to this question.

Naoto

From naoto.sato at oracle.com  Tue Jan  8 17:46:27 2019
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 8 Jan 2019 09:46:27 -0800
Subject: <i18n dev> [12] RFR: 8216176: Clarify the singleton description in
 j.t.c.JapaneseEra class
Message-ID: <540301bf-d743-9780-9294-fe0832faa49b@oracle.com>

Hello,

Please review the change for the following issue:

Issue: https://bugs.openjdk.java.net/browse/JDK-8216176
CSR: https://bugs.openjdk.java.net/browse/JDK-8216177

The proposed changeset is located at:

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

This is a simple one line change that is clarifying the era singleton 
description, which was added with the fix to 8212941.

Naoto

From rachna.goel at oracle.com  Wed Jan  9 06:35:43 2019
From: rachna.goel at oracle.com (Rachna Goel)
Date: Wed, 9 Jan 2019 12:05:43 +0530
Subject: <i18n dev> [12] RFR: 8216176: Clarify the singleton description
 in j.t.c.JapaneseEra class
In-Reply-To: <540301bf-d743-9780-9294-fe0832faa49b@oracle.com>
References: <540301bf-d743-9780-9294-fe0832faa49b@oracle.com>
Message-ID: <9cfef47f-19f8-48f8-d2d4-dd06ff89812d@oracle.com>

Looks good to me.

On 1/8/19 11:16 PM, Naoto Sato wrote:
> Hello,
>
> Please review the change for the following issue:
>
> Issue: https://bugs.openjdk.java.net/browse/JDK-8216176
> CSR: https://bugs.openjdk.java.net/browse/JDK-8216177
>
> The proposed changeset is located at:
>
> http://cr.openjdk.java.net/~naoto/8216176/webrev.00/
>
> This is a simple one line change that is clarifying the era singleton 
> description, which was added with the fix to 8212941.
>
> Naoto

-- 
Thanks,
Rachna


From nokok.kz at gmail.com  Fri Jan 11 09:57:19 2019
From: nokok.kz at gmail.com (=?UTF-8?B?5pWw5rKiIOWJh+W+gQ==?=)
Date: Fri, 11 Jan 2019 18:57:19 +0900
Subject: <i18n dev> [PATCH] Fix typo in usage for javac
Message-ID: <CAFH+Os6vX8CRCWR1LyVHCSboqQ1WL+y6PGOdiqAkQYqomDQE1Q@mail.gmail.com>

Hi all,

I noticed a typo in the usage of javac(in Japanese).

jdk-13-ea+3
  --release <release>
        ????????????????????????????????: 7, 8, 9, 10, 11, 13

jdk-13-ea+1
  --release <release>
        ???VM??????????????????????????????: 7, 8, 9, 10, 11, 13

Patch attached below. Could you please review it.

diff -r e832101ff63c
src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac_ja.properties
--- a/src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac_ja.properties
Wed Jan 09 14:46:40 2019 +0100
+++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac_ja.properties
Fri Jan 11 18:32:12 2019 +0900
@@ -53,7 +53,7 @@
 javac.opt.encoding=\u30BD\u30FC\u30B9\u30FB\u30D5\u30A1\u30A4\u30EB\u304C\u4F7F\u7528\u3059\u308B\u6587\u5B57\u30A8\u30F3\u30B3\u30FC\u30C7\u30A3\u30F3\u30B0\u3092\u6307\u5B9A\u3059\u308B
 javac.opt.profile=\u4F7F\u7528\u3055\u308C\u3066\u3044\u308BAPI\u304C\u6307\u5B9A\u3057\u305F\u30D7\u30ED\u30D5\u30A1\u30A4\u30EB\u3067\u4F7F\u7528\u53EF\u80FD\u304B\u3069\u3046\u304B\u3092\u78BA\u8A8D\u3057\u307E\u3059
 javac.opt.target=\u7279\u5B9A\u306EVM\u30D0\u30FC\u30B8\u30E7\u30F3\u7528\u306E\u30AF\u30E9\u30B9\u30FB\u30D5\u30A1\u30A4\u30EB\u3092\u751F\u6210\u3057\u307E\u3059\u3002\u30B5\u30DD\u30FC\u30C8\u3055\u308C\u3066\u3044\u308B\u30D0\u30FC\u30B8\u30E7\u30F3:
{0}
-javac.opt.release=\u7279\u5B9A\u306E\u30EA\u30EA\u30FC\u30B9\u7528\u306B\u306B\u30B3\u30F3\u30D1\u30A4\u30EB\u3057\u307E\u3059\u3002\u30B5\u30DD\u30FC\u30C8\u3055\u308C\u3066\u3044\u308B\u30EA\u30EA\u30FC\u30B9:
{0}
+javac.opt.release=\u7279\u5B9A\u306E\u30EA\u30EA\u30FC\u30B9\u7528\u306B\u30B3\u30F3\u30D1\u30A4\u30EB\u3057\u307E\u3059\u3002\u30B5\u30DD\u30FC\u30C8\u3055\u308C\u3066\u3044\u308B\u30EA\u30EA\u30FC\u30B9:
{0}
 javac.opt.source=\u6307\u5B9A\u3055\u308C\u305F\u30EA\u30EA\u30FC\u30B9\u3068\u30BD\u30FC\u30B9\u306E\u4E92\u63DB\u6027\u3092\u4FDD\u6301\u3057\u307E\u3059\u3002\u30B5\u30DD\u30FC\u30C8\u3055\u308C\u3066\u3044\u308B\u30EA\u30EA\u30FC\u30B9:
{0}
 javac.opt.Werror=\u8B66\u544A\u304C\u767A\u751F\u3057\u305F\u5834\u5408\u306B\u30B3\u30F3\u30D1\u30A4\u30EB\u3092\u7D42\u4E86\u3059\u308B
 javac.opt.A=\u6CE8\u91C8\u30D7\u30ED\u30BB\u30C3\u30B5\u306B\u6E21\u3055\u308C\u308B\u30AA\u30D7\u30B7\u30E7\u30F3

Best Regards,
Noriyuki

From naoto.sato at oracle.com  Fri Jan 11 19:15:49 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Fri, 11 Jan 2019 11:15:49 -0800
Subject: <i18n dev> [13] RFR: Correct UnicodeDecoder U+FFFE handling
Message-ID: <9fb04cbc-5843-aefd-5612-631fbc37ab6e@oracle.com>

Hello,

Please review the fix to the following issue:

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

The proposed changeset is located at:

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

This issue was previously discussed in 
https://bugs.openjdk.java.net/browse/JDK-8150449 and was closed as "not 
an issue" for JDK8. Unicode Consortium then made a corrigendum to 
Unicode 7 that recommends passing through of the code point. To conform 
to the standard, the offending test/error return has been removed, based 
on the recommendation in the previous consideration on 8150449.

Naoto

From li.jiang at oracle.com  Sat Jan 12 12:52:21 2019
From: li.jiang at oracle.com (li.jiang at oracle.com)
Date: Sat, 12 Jan 2019 20:52:21 +0800
Subject: <i18n dev> [PATCH] Fix typo in usage for javac
In-Reply-To: <CAFH+Os6vX8CRCWR1LyVHCSboqQ1WL+y6PGOdiqAkQYqomDQE1Q@mail.gmail.com>
References: <CAFH+Os6vX8CRCWR1LyVHCSboqQ1WL+y6PGOdiqAkQYqomDQE1Q@mail.gmail.com>
Message-ID: <3e0baf53-6490-c0dd-8fe3-77fa27c27d15@oracle.com>

Hi Noriyuki,

Very appreciated to report this typo and contribute the patch.

This typo issue was introduced by the JDK 12 msg drop 10, and into JDK 
13 with the forward port. As we need to fix it on translation memory 
side first, so we don't fix it on resource files in repo directly.

File a bug: https://bugs.openjdk.java.net/browse/JDK-8216590

The fix would be integrated with JDK 12 msg drop 20, and then fix it in 
JDK 13 with forward port.

Thanks,
Leo

On 1/11/19 5:57 PM, ?? ?? wrote:
> Hi all,
> 
> I noticed a typo in the usage of javac(in Japanese).
> 
> jdk-13-ea+3
>    --release <release>
>          ????????????????????????????????: 7, 8, 9, 10, 11, 13
> 
> jdk-13-ea+1
>    --release <release>
>          ???VM??????????????????????????????: 7, 8, 9, 10, 11, 13
> 
> Patch attached below. Could you please review it.
> 
> diff -r e832101ff63c
> src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac_ja.properties
> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac_ja.properties
> Wed Jan 09 14:46:40 2019 +0100
> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac_ja.properties
> Fri Jan 11 18:32:12 2019 +0900
> @@ -53,7 +53,7 @@
>   javac.opt.encoding=\u30BD\u30FC\u30B9\u30FB\u30D5\u30A1\u30A4\u30EB\u304C\u4F7F\u7528\u3059\u308B\u6587\u5B57\u30A8\u30F3\u30B3\u30FC\u30C7\u30A3\u30F3\u30B0\u3092\u6307\u5B9A\u3059\u308B
>   javac.opt.profile=\u4F7F\u7528\u3055\u308C\u3066\u3044\u308BAPI\u304C\u6307\u5B9A\u3057\u305F\u30D7\u30ED\u30D5\u30A1\u30A4\u30EB\u3067\u4F7F\u7528\u53EF\u80FD\u304B\u3069\u3046\u304B\u3092\u78BA\u8A8D\u3057\u307E\u3059
>   javac.opt.target=\u7279\u5B9A\u306EVM\u30D0\u30FC\u30B8\u30E7\u30F3\u7528\u306E\u30AF\u30E9\u30B9\u30FB\u30D5\u30A1\u30A4\u30EB\u3092\u751F\u6210\u3057\u307E\u3059\u3002\u30B5\u30DD\u30FC\u30C8\u3055\u308C\u3066\u3044\u308B\u30D0\u30FC\u30B8\u30E7\u30F3:
> {0}
> -javac.opt.release=\u7279\u5B9A\u306E\u30EA\u30EA\u30FC\u30B9\u7528\u306B\u306B\u30B3\u30F3\u30D1\u30A4\u30EB\u3057\u307E\u3059\u3002\u30B5\u30DD\u30FC\u30C8\u3055\u308C\u3066\u3044\u308B\u30EA\u30EA\u30FC\u30B9:
> {0}
> +javac.opt.release=\u7279\u5B9A\u306E\u30EA\u30EA\u30FC\u30B9\u7528\u306B\u30B3\u30F3\u30D1\u30A4\u30EB\u3057\u307E\u3059\u3002\u30B5\u30DD\u30FC\u30C8\u3055\u308C\u3066\u3044\u308B\u30EA\u30EA\u30FC\u30B9:
> {0}
>   javac.opt.source=\u6307\u5B9A\u3055\u308C\u305F\u30EA\u30EA\u30FC\u30B9\u3068\u30BD\u30FC\u30B9\u306E\u4E92\u63DB\u6027\u3092\u4FDD\u6301\u3057\u307E\u3059\u3002\u30B5\u30DD\u30FC\u30C8\u3055\u308C\u3066\u3044\u308B\u30EA\u30EA\u30FC\u30B9:
> {0}
>   javac.opt.Werror=\u8B66\u544A\u304C\u767A\u751F\u3057\u305F\u5834\u5408\u306B\u30B3\u30F3\u30D1\u30A4\u30EB\u3092\u7D42\u4E86\u3059\u308B
>   javac.opt.A=\u6CE8\u91C8\u30D7\u30ED\u30BB\u30C3\u30B5\u306B\u6E21\u3055\u308C\u308B\u30AA\u30D7\u30B7\u30E7\u30F3
> 
> Best Regards,
> Noriyuki
> 

From nokok.kz at gmail.com  Sat Jan 12 17:12:53 2019
From: nokok.kz at gmail.com (Noriyuki Kazusawa)
Date: Sun, 13 Jan 2019 02:12:53 +0900
Subject: <i18n dev> [PATCH] Fix typo in usage for javac
In-Reply-To: <3e0baf53-6490-c0dd-8fe3-77fa27c27d15@oracle.com>
References: <CAFH+Os6vX8CRCWR1LyVHCSboqQ1WL+y6PGOdiqAkQYqomDQE1Q@mail.gmail.com>
 <3e0baf53-6490-c0dd-8fe3-77fa27c27d15@oracle.com>
Message-ID: <CAFH+Os7mZZarMC-fNkNocmxdMmQJiNmqypCSLuSmvbBY=Oh__A@mail.gmail.com>

Hi Leo,

Thank you very much for your reply and investigation!
I'm looking forward to being fixed. :-)

Thanks,
Noriyuki

2019?1?12?(?) 21:52 <li.jiang at oracle.com>:
>
> Hi Noriyuki,
>
> Very appreciated to report this typo and contribute the patch.
>
> This typo issue was introduced by the JDK 12 msg drop 10, and into JDK
> 13 with the forward port. As we need to fix it on translation memory
> side first, so we don't fix it on resource files in repo directly.
>
> File a bug: https://bugs.openjdk.java.net/browse/JDK-8216590
>
> The fix would be integrated with JDK 12 msg drop 20, and then fix it in
> JDK 13 with forward port.
>
> Thanks,
> Leo
>
> On 1/11/19 5:57 PM, ?? ?? wrote:
> > Hi all,
> >
> > I noticed a typo in the usage of javac(in Japanese).
> >
> > jdk-13-ea+3
> >    --release <release>
> >          ????????????????????????????????: 7, 8, 9, 10, 11, 13
> >
> > jdk-13-ea+1
> >    --release <release>
> >          ???VM??????????????????????????????: 7, 8, 9, 10, 11, 13
> >
> > Patch attached below. Could you please review it.
> >
> > diff -r e832101ff63c
> > src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac_ja.properties
> > --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac_ja.properties
> > Wed Jan 09 14:46:40 2019 +0100
> > +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac_ja.properties
> > Fri Jan 11 18:32:12 2019 +0900
> > @@ -53,7 +53,7 @@
> >   javac.opt.encoding=\u30BD\u30FC\u30B9\u30FB\u30D5\u30A1\u30A4\u30EB\u304C\u4F7F\u7528\u3059\u308B\u6587\u5B57\u30A8\u30F3\u30B3\u30FC\u30C7\u30A3\u30F3\u30B0\u3092\u6307\u5B9A\u3059\u308B
> >   javac.opt.profile=\u4F7F\u7528\u3055\u308C\u3066\u3044\u308BAPI\u304C\u6307\u5B9A\u3057\u305F\u30D7\u30ED\u30D5\u30A1\u30A4\u30EB\u3067\u4F7F\u7528\u53EF\u80FD\u304B\u3069\u3046\u304B\u3092\u78BA\u8A8D\u3057\u307E\u3059
> >   javac.opt.target=\u7279\u5B9A\u306EVM\u30D0\u30FC\u30B8\u30E7\u30F3\u7528\u306E\u30AF\u30E9\u30B9\u30FB\u30D5\u30A1\u30A4\u30EB\u3092\u751F\u6210\u3057\u307E\u3059\u3002\u30B5\u30DD\u30FC\u30C8\u3055\u308C\u3066\u3044\u308B\u30D0\u30FC\u30B8\u30E7\u30F3:
> > {0}
> > -javac.opt.release=\u7279\u5B9A\u306E\u30EA\u30EA\u30FC\u30B9\u7528\u306B\u306B\u30B3\u30F3\u30D1\u30A4\u30EB\u3057\u307E\u3059\u3002\u30B5\u30DD\u30FC\u30C8\u3055\u308C\u3066\u3044\u308B\u30EA\u30EA\u30FC\u30B9:
> > {0}
> > +javac.opt.release=\u7279\u5B9A\u306E\u30EA\u30EA\u30FC\u30B9\u7528\u306B\u30B3\u30F3\u30D1\u30A4\u30EB\u3057\u307E\u3059\u3002\u30B5\u30DD\u30FC\u30C8\u3055\u308C\u3066\u3044\u308B\u30EA\u30EA\u30FC\u30B9:
> > {0}
> >   javac.opt.source=\u6307\u5B9A\u3055\u308C\u305F\u30EA\u30EA\u30FC\u30B9\u3068\u30BD\u30FC\u30B9\u306E\u4E92\u63DB\u6027\u3092\u4FDD\u6301\u3057\u307E\u3059\u3002\u30B5\u30DD\u30FC\u30C8\u3055\u308C\u3066\u3044\u308B\u30EA\u30EA\u30FC\u30B9:
> > {0}
> >   javac.opt.Werror=\u8B66\u544A\u304C\u767A\u751F\u3057\u305F\u5834\u5408\u306B\u30B3\u30F3\u30D1\u30A4\u30EB\u3092\u7D42\u4E86\u3059\u308B
> >   javac.opt.A=\u6CE8\u91C8\u30D7\u30ED\u30BB\u30C3\u30B5\u306B\u6E21\u3055\u308C\u308B\u30AA\u30D7\u30B7\u30E7\u30F3
> >
> > Best Regards,
> > Noriyuki
> >

From takiguc at linux.vnet.ibm.com  Wed Jan 16 11:13:09 2019
From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi)
Date: Wed, 16 Jan 2019 20:13:09 +0900
Subject: <i18n dev> <AWT Dev> RFR: 8212678 Windows IME related patch
In-Reply-To: <75b8dabc3f52417885a0a1f1e3aec719@linux.vnet.ibm.com>
References: <c8cc78edbcc0c10145e4844805faa2e9@linux.vnet.ibm.com>
 <d114ee98-9776-ef14-2264-04d1b52258fe@oracle.com>
 <75b8dabc3f52417885a0a1f1e3aec719@linux.vnet.ibm.com>
Message-ID: <1704b65b98f5521a57fdea529a597671@linux.vnet.ibm.com>

Hello.

Could you review the fix ?

Bug:    https://bugs.openjdk.java.net/browse/JDK-8212678
Change: https://cr.openjdk.java.net/~itakiguchi/8212678/webrev.01/

3 issues were combined.
2 issues are recreatable on English Windows.

Screen shots and movies are attached into JDK-8212678.
Please check them.

I'd like to obtain a sponsor for this issue.

Thanks,
Ichiroh Takiguchi
IBM Japan, Ltd.

On 2018-11-18 22:22, Ichiroh Takiguchi wrote:
> Hello.
> 
> Could you review the fix ?
> 
> Bug:    https://bugs.openjdk.java.net/browse/JDK-8212678
> Change: http://cr.openjdk.java.net/~aleonard/winime/webrev.00/
> 
> Test instruction is in JDK-8212678.
> This fix may improve CJK IME operation.
> 
> I'd like to obtain a sponsor for this issue.
> 
> Thanks,
> Ichiroh Takiguchi
> IBM Japan, Ltd.
> 
> On 2018-06-15 02:26, Phil Race wrote:
>> This should go to i18n-dev as well.
>> 
>> -phil.
>> 
>> On 06/14/2018 10:14 AM, Ichiroh Takiguchi wrote:
>>> Hello,
>>> IBM would like to contribute Windows IME related Java Input Method 
>>> Framework patch to OpenJDK project.
>>> 
>>> Issue:
>>> This patch can fix following issues.
>>> A: Cannot display surrogate pair character on Windows floating IME 
>>> window for passive component
>>> B: Control Windows IME status by using InputSubset and UnicodeBlock 
>>> for CJK countries
>>> C: Check preedit string availability for Windows Chinese IME
>>> 
>>> To recreate each issue.
>>> 
>>> Issue A:
>>> 1. Run SwingSet2 Java demo program with Japanese IME.
>>> 2. Click InternalFrameDemo's "Frame 0".
>>> 3. Turn on Japanese IME, then type "2000B" and press F5 key.
>>> The character is not displayed properly. [1]
>>> 
>>> Issue B:
>>> Test program (ImSubsetsTest.java) is as follow:
>>> http://cr.openjdk.java.net/~aleonard/winime/ImSubsetsTest.java
>>> 
>>> 1. Compile and run ImSubsetsTest with CJK IMEs
>>> 2. Select language (ja:Japanese, ko:Korean, zh: Chinese).
>>> Windows IME (same langugae's one) should be turned on.
>>> 3. Click  JTextField (active component) or JButton (passive 
>>> component)
>>> (Please check IM status is changed or not)
>>> 4. Click different color's JTextField (active component) or JButton 
>>> (passive component)
>>> (Please check IM status is changed or not)
>>> 5. Following operations did not work
>>> Korean IME : HANJA->LATIN_DIGIT,BASIC_LATIN
>>> Chinese IME : FULLWIDTH_DIGITS->LATIN_DIGIT,BASIC_LATIN
>>> 
>>> Issue C:
>>> Test program is as follows:
>>> ======
>>> import javax.swing.*;
>>> 
>>> public class IMFTestA extends JFrame {
>>>   IMFTestA(int width, int height, int x, int y) {
>>>     super("JTextArea");
>>>     add(new JTextArea());
>>>     setSize(width, height);
>>>     setLocation(x, y);
>>>     setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
>>>     setVisible(true);
>>>   }
>>>   public static void main(String[] args) {
>>>     new IMFTestA(300, 200, 0, 0);
>>>     new IMFTestA(300, 200, 300, 0);
>>>   }
>>> }
>>> ======
>>> 
>>> On Chinese IME (Microsoft Pinyin ABC),
>>> 1. Compile and run IMFTestA
>>> 2. Click one of JTextArea window, turn ON Chinese IME
>>> 3. Click the other window, turn ON Chinese IME
>>> 4. Type "nihao", then preedit string is displayed
>>> 5. Click the other window, turn OFF Chinese IME
>>> 6. Click the other window, preedit string is still displayed but it's 
>>> not convertable
>>> 
>>> Reason:
>>> Issue A, proper font is not specified for passive component
>>> Issue B, IME mode setting for CJK Windows IME is not correct
>>> Issue C, Chinese Windows IME shares IME status between windows, Java 
>>> needs to check preedit string is available or not
>>> 
>>> I'd like contribute following 3 files:
>>> M src/java.desktop/windows/classes/sun/awt/windows/WInputMethod.java
>>> M src/java.desktop/windows/native/libawt/windows/awt_Component.cpp
>>> M src/java.desktop/windows/native/libawt/windows/awt_InputMethod.cpp
>>> http://cr.openjdk.java.net/~aleonard/winime/webrev.00/
>>> 
>>> I appreciate any feedback please, and how I would go about obtaining 
>>> a sponsor and contributor?
>>> 
>>> [1] http://unicode.org/cgi-bin/GetUnihanData.pl?codepoint=2000B
>>> 
>>> Thanks,
>>> Ichiroh Takiguchi
>>> IBM Japan, Ltd.
>>> 


From naoto.sato at oracle.com  Thu Jan 17 00:20:24 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Wed, 16 Jan 2019 16:20:24 -0800
Subject: <i18n dev> [13] RFR: 8216969: ParseException thrown for certain
 months with russian locale
Message-ID: <c4ca4ed1-e027-968b-146d-256de0da7592@oracle.com>

Hi,

Please review the fix to the following issue:

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

The proposed changeset is located at:

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

For parsing the context sensitive month 'M', the logic was to look for 
the best match for the short name regardless of the styles. Changed the 
parsing code to take the context into account.

Naoto

From nishit.jain at oracle.com  Thu Jan 17 07:07:18 2019
From: nishit.jain at oracle.com (Nishit Jain)
Date: Thu, 17 Jan 2019 12:37:18 +0530
Subject: <i18n dev> [13] RFR: 8210583: Base64.Encoder incorrectly throws
 NegativeArraySizeException
Message-ID: <869444f3-645e-33f6-89b0-a223ea704d39@oracle.com>

Hi,

Please review the fix for 8210583

Bug: https://bugs.openjdk.java.net/browse/JDK-8210583
Webrev: http://cr.openjdk.java.net/~nishjain/8210583/webrev.03/
CSR: https://bugs.openjdk.java.net/browse/JDK-8215633

Issue: Base64.Encoder.encode and Base64.Decoder.decode methods 
incorrectly throw unspecified exception e.g. NegativeArraySizeException, 
when the input byte array size is too large such that the calculated 
output byte size goes beyond the max-integer boundary and wraps around.

Fix: Throw an OutOfMemoryError if the output byte array/buffer or memory 
can not be allocated. There is an unrelated change in 
encodeToString(byte[]) where a string instance is created using 
JavaLangAccess.newStringNoRepl(byte[], ISO_8859_1)instead of string 
constructor, to save memory.

Regards,
Nishit Jain

From nishit.jain at oracle.com  Thu Jan 17 10:57:11 2019
From: nishit.jain at oracle.com (Nishit Jain)
Date: Thu, 17 Jan 2019 16:27:11 +0530
Subject: <i18n dev> [13] RFR: 8216969: ParseException thrown for certain
 months with russian locale
In-Reply-To: <c4ca4ed1-e027-968b-146d-256de0da7592@oracle.com>
References: <c4ca4ed1-e027-968b-146d-256de0da7592@oracle.com>
Message-ID: <3e12f97f-c619-6546-043e-0414ca32b227@oracle.com>

Hi Naoto,

Looks good to me. Just a small suggestion.

- To improve readability, can we declare "standalone mask" (0x8000) as a 
static field and use that at all the places?

Regards,
Nishit Jain
On 17-01-2019 05:50, naoto.sato at oracle.com wrote:
> Hi,
>
> Please review the fix to the following issue:
>
> https://bugs.openjdk.java.net/browse/JDK-8216969
>
> The proposed changeset is located at:
>
> http://cr.openjdk.java.net/~naoto/8216969/webrev.00/
>
> For parsing the context sensitive month 'M', the logic was to look for 
> the best match for the short name regardless of the styles. Changed 
> the parsing code to take the context into account.
>
> Naoto


From naoto.sato at oracle.com  Thu Jan 17 16:37:03 2019
From: naoto.sato at oracle.com (Naoto Sato)
Date: Thu, 17 Jan 2019 08:37:03 -0800
Subject: <i18n dev> [13] RFR: 8216969: ParseException thrown for certain
 months with russian locale
In-Reply-To: <3e12f97f-c619-6546-043e-0414ca32b227@oracle.com>
References: <c4ca4ed1-e027-968b-146d-256de0da7592@oracle.com>
 <3e12f97f-c619-6546-043e-0414ca32b227@oracle.com>
Message-ID: <550ab41a-32ba-b0b0-d358-9c21152e1736@oracle.com>

Hi Nishit,

Thanks. Updated:

http://cr.openjdk.java.net/~naoto/8216969/webrev.01/

Naoto

On 1/17/19 2:57 AM, Nishit Jain wrote:
> Hi Naoto,
> 
> Looks good to me. Just a small suggestion.
> 
> - To improve readability, can we declare "standalone mask" (0x8000) as a 
> static field and use that at all the places?
> 
> Regards,
> Nishit Jain
> On 17-01-2019 05:50, naoto.sato at oracle.com wrote:
>> Hi,
>>
>> Please review the fix to the following issue:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8216969
>>
>> The proposed changeset is located at:
>>
>> http://cr.openjdk.java.net/~naoto/8216969/webrev.00/
>>
>> For parsing the context sensitive month 'M', the logic was to look for 
>> the best match for the short name regardless of the styles. Changed 
>> the parsing code to take the context into account.
>>
>> Naoto
> 

From nishit.jain at oracle.com  Fri Jan 18 09:57:14 2019
From: nishit.jain at oracle.com (Nishit Jain)
Date: Fri, 18 Jan 2019 15:27:14 +0530
Subject: <i18n dev> [13] RFR: 8216969: ParseException thrown for certain
 months with russian locale
In-Reply-To: <550ab41a-32ba-b0b0-d358-9c21152e1736@oracle.com>
References: <c4ca4ed1-e027-968b-146d-256de0da7592@oracle.com>
 <3e12f97f-c619-6546-043e-0414ca32b227@oracle.com>
 <550ab41a-32ba-b0b0-d358-9c21152e1736@oracle.com>
Message-ID: <4f12d121-327f-ddf6-dbf0-afc9e6f5eb91@oracle.com>

Looks Good.

Regards,
Nishit Jain
On 17-01-2019 22:07, Naoto Sato wrote:
> Hi Nishit,
>
> Thanks. Updated:
>
> http://cr.openjdk.java.net/~naoto/8216969/webrev.01/
>
> Naoto
>
> On 1/17/19 2:57 AM, Nishit Jain wrote:
>> Hi Naoto,
>>
>> Looks good to me. Just a small suggestion.
>>
>> - To improve readability, can we declare "standalone mask" (0x8000) 
>> as a static field and use that at all the places?
>>
>> Regards,
>> Nishit Jain
>> On 17-01-2019 05:50, naoto.sato at oracle.com wrote:
>>> Hi,
>>>
>>> Please review the fix to the following issue:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8216969
>>>
>>> The proposed changeset is located at:
>>>
>>> http://cr.openjdk.java.net/~naoto/8216969/webrev.00/
>>>
>>> For parsing the context sensitive month 'M', the logic was to look 
>>> for the best match for the short name regardless of the styles. 
>>> Changed the parsing code to take the context into account.
>>>
>>> Naoto
>>


From naoto.sato at oracle.com  Fri Jan 18 23:45:26 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Fri, 18 Jan 2019 15:45:26 -0800
Subject: <i18n dev> [13] RFR: 8216969: ParseException thrown for certain
 months with russian locale
In-Reply-To: <4f12d121-327f-ddf6-dbf0-afc9e6f5eb91@oracle.com>
References: <c4ca4ed1-e027-968b-146d-256de0da7592@oracle.com>
 <3e12f97f-c619-6546-043e-0414ca32b227@oracle.com>
 <550ab41a-32ba-b0b0-d358-9c21152e1736@oracle.com>
 <4f12d121-327f-ddf6-dbf0-afc9e6f5eb91@oracle.com>
Message-ID: <00231b14-8c03-8224-0c65-571cb26be4f8@oracle.com>

Gentle reminder. Still waiting for reviews from OpenJDK Reviewers.

Naoto

On 1/18/19 1:57 AM, Nishit Jain wrote:
> Looks Good.
> 
> Regards,
> Nishit Jain
> On 17-01-2019 22:07, Naoto Sato wrote:
>> Hi Nishit,
>>
>> Thanks. Updated:
>>
>> http://cr.openjdk.java.net/~naoto/8216969/webrev.01/
>>
>> Naoto
>>
>> On 1/17/19 2:57 AM, Nishit Jain wrote:
>>> Hi Naoto,
>>>
>>> Looks good to me. Just a small suggestion.
>>>
>>> - To improve readability, can we declare "standalone mask" (0x8000) 
>>> as a static field and use that at all the places?
>>>
>>> Regards,
>>> Nishit Jain
>>> On 17-01-2019 05:50, naoto.sato at oracle.com wrote:
>>>> Hi,
>>>>
>>>> Please review the fix to the following issue:
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8216969
>>>>
>>>> The proposed changeset is located at:
>>>>
>>>> http://cr.openjdk.java.net/~naoto/8216969/webrev.00/
>>>>
>>>> For parsing the context sensitive month 'M', the logic was to look 
>>>> for the best match for the short name regardless of the styles. 
>>>> Changed the parsing code to take the context into account.
>>>>
>>>> Naoto
>>>
> 

From takiguc at linux.vnet.ibm.com  Tue Jan 22 04:08:18 2019
From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi)
Date: Tue, 22 Jan 2019 13:08:18 +0900
Subject: <i18n dev> <AWT Dev> RFR: X11 default visual support for IM
 status window on VNC
In-Reply-To: <533c8ab5-31d9-58bd-4250-03e1c24f6f23@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>
 <674fa1d548764758a051953ce9a97d95@linux.vnet.ibm.com>
 <47596f79d10fcfac856172db4d8cffd2@linux.vnet.ibm.com>
 <533c8ab5-31d9-58bd-4250-03e1c24f6f23@oracle.com>
Message-ID: <d856f0b2b5699f693dfb8786fbbd453d@linux.vnet.ibm.com>

Hello Sergey.

Sorry, code conflict was there.
I fixed code conflict and modified Copyright year.

Could you review the fix again ?

Bug:    https://bugs.openjdk.java.net/browse/JDK-8212677
Change: https://cr.openjdk.java.net/~itakiguchi/8212677/webrev.01/

Thanks,
Ichiroh Takiguchi
IBM Japan, Ltd.

On 2018-12-01 09:49, Sergey Bylokhov wrote:
> Looks fine, if there are no other comments I'll push the fix.
> 
> On 26/11/2018 05:02, Ichiroh Takiguchi wrote:
>> Hello.
>> 
>> Could you review the fix ?
>> 
>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8212677
>> Change: https://cr.openjdk.java.net/~itakiguchi/8212677/webrev.00/
>> 
>> Screen shots are in JDK-8212677.
>> 
>> I'd like to obtain a sponsor for this issue.
>> 
>> Thanks,
>> Ichiroh Takiguchi
>> IBM Japan, Ltd.
>> 
>> On 2018-06-21 21:58, Ichiroh Takiguchi wrote:
>>> 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 takiguc at linux.vnet.ibm.com  Wed Jan 23 12:18:37 2019
From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi)
Date: Wed, 23 Jan 2019 21:18:37 +0900
Subject: <i18n dev> <AWT Dev> RFR: 8212678 Windows IME related patch
In-Reply-To: <1704b65b98f5521a57fdea529a597671@linux.vnet.ibm.com>
References: <c8cc78edbcc0c10145e4844805faa2e9@linux.vnet.ibm.com>
 <d114ee98-9776-ef14-2264-04d1b52258fe@oracle.com>
 <75b8dabc3f52417885a0a1f1e3aec719@linux.vnet.ibm.com>
 <1704b65b98f5521a57fdea529a597671@linux.vnet.ibm.com>
Message-ID: <65a12ea2c1e684c5ccf236db37c2a9ad@linux.vnet.ibm.com>

Hello.

Could you review the fix and give me your suggestion ?

Thanks,
Ichiroh Takiguchi

On 2019-01-16 20:13, Ichiroh Takiguchi wrote:
> Hello.
> 
> Could you review the fix ?
> 
> Bug:    https://bugs.openjdk.java.net/browse/JDK-8212678
> Change: https://cr.openjdk.java.net/~itakiguchi/8212678/webrev.01/
> 
> 3 issues were combined.
> 2 issues are recreatable on English Windows.
> 
> Screen shots and movies are attached into JDK-8212678.
> Please check them.
> 
> I'd like to obtain a sponsor for this issue.
> 
> Thanks,
> Ichiroh Takiguchi
> IBM Japan, Ltd.
> 
> On 2018-11-18 22:22, Ichiroh Takiguchi wrote:
>> Hello.
>> 
>> Could you review the fix ?
>> 
>> Bug:    https://bugs.openjdk.java.net/browse/JDK-8212678
>> Change: http://cr.openjdk.java.net/~aleonard/winime/webrev.00/
>> 
>> Test instruction is in JDK-8212678.
>> This fix may improve CJK IME operation.
>> 
>> I'd like to obtain a sponsor for this issue.
>> 
>> Thanks,
>> Ichiroh Takiguchi
>> IBM Japan, Ltd.
>> 
>> On 2018-06-15 02:26, Phil Race wrote:
>>> This should go to i18n-dev as well.
>>> 
>>> -phil.
>>> 
>>> On 06/14/2018 10:14 AM, Ichiroh Takiguchi wrote:
>>>> Hello,
>>>> IBM would like to contribute Windows IME related Java Input Method 
>>>> Framework patch to OpenJDK project.
>>>> 
>>>> Issue:
>>>> This patch can fix following issues.
>>>> A: Cannot display surrogate pair character on Windows floating IME 
>>>> window for passive component
>>>> B: Control Windows IME status by using InputSubset and UnicodeBlock 
>>>> for CJK countries
>>>> C: Check preedit string availability for Windows Chinese IME
>>>> 
>>>> To recreate each issue.
>>>> 
>>>> Issue A:
>>>> 1. Run SwingSet2 Java demo program with Japanese IME.
>>>> 2. Click InternalFrameDemo's "Frame 0".
>>>> 3. Turn on Japanese IME, then type "2000B" and press F5 key.
>>>> The character is not displayed properly. [1]
>>>> 
>>>> Issue B:
>>>> Test program (ImSubsetsTest.java) is as follow:
>>>> http://cr.openjdk.java.net/~aleonard/winime/ImSubsetsTest.java
>>>> 
>>>> 1. Compile and run ImSubsetsTest with CJK IMEs
>>>> 2. Select language (ja:Japanese, ko:Korean, zh: Chinese).
>>>> Windows IME (same langugae's one) should be turned on.
>>>> 3. Click  JTextField (active component) or JButton (passive 
>>>> component)
>>>> (Please check IM status is changed or not)
>>>> 4. Click different color's JTextField (active component) or JButton 
>>>> (passive component)
>>>> (Please check IM status is changed or not)
>>>> 5. Following operations did not work
>>>> Korean IME : HANJA->LATIN_DIGIT,BASIC_LATIN
>>>> Chinese IME : FULLWIDTH_DIGITS->LATIN_DIGIT,BASIC_LATIN
>>>> 
>>>> Issue C:
>>>> Test program is as follows:
>>>> ======
>>>> import javax.swing.*;
>>>> 
>>>> public class IMFTestA extends JFrame {
>>>>   IMFTestA(int width, int height, int x, int y) {
>>>>     super("JTextArea");
>>>>     add(new JTextArea());
>>>>     setSize(width, height);
>>>>     setLocation(x, y);
>>>>     setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
>>>>     setVisible(true);
>>>>   }
>>>>   public static void main(String[] args) {
>>>>     new IMFTestA(300, 200, 0, 0);
>>>>     new IMFTestA(300, 200, 300, 0);
>>>>   }
>>>> }
>>>> ======
>>>> 
>>>> On Chinese IME (Microsoft Pinyin ABC),
>>>> 1. Compile and run IMFTestA
>>>> 2. Click one of JTextArea window, turn ON Chinese IME
>>>> 3. Click the other window, turn ON Chinese IME
>>>> 4. Type "nihao", then preedit string is displayed
>>>> 5. Click the other window, turn OFF Chinese IME
>>>> 6. Click the other window, preedit string is still displayed but 
>>>> it's not convertable
>>>> 
>>>> Reason:
>>>> Issue A, proper font is not specified for passive component
>>>> Issue B, IME mode setting for CJK Windows IME is not correct
>>>> Issue C, Chinese Windows IME shares IME status between windows, Java 
>>>> needs to check preedit string is available or not
>>>> 
>>>> I'd like contribute following 3 files:
>>>> M src/java.desktop/windows/classes/sun/awt/windows/WInputMethod.java
>>>> M src/java.desktop/windows/native/libawt/windows/awt_Component.cpp
>>>> M src/java.desktop/windows/native/libawt/windows/awt_InputMethod.cpp
>>>> http://cr.openjdk.java.net/~aleonard/winime/webrev.00/
>>>> 
>>>> I appreciate any feedback please, and how I would go about obtaining 
>>>> a sponsor and contributor?
>>>> 
>>>> [1] http://unicode.org/cgi-bin/GetUnihanData.pl?codepoint=2000B
>>>> 
>>>> Thanks,
>>>> Ichiroh Takiguchi
>>>> IBM Japan, Ltd.
>>>> 


From naoto.sato at oracle.com  Wed Jan 23 17:47:48 2019
From: naoto.sato at oracle.com (Naoto Sato)
Date: Wed, 23 Jan 2019 09:47:48 -0800
Subject: <i18n dev> [13] RFR: 8217366: ZoneStrings are not populated for all
	the Locales
Message-ID: <64a323dc-c8ee-5a2a-03e7-7255d684b639@oracle.com>

Hi,

Please review the fix to the following issue:

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

The proposed changeset is located at:

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

The gist of the issue is that CLDR's "no inheritance marker" slipped 
into the final zone strings array, which should be converted to GMT format.

Naoto

From naoto.sato at oracle.com  Fri Jan 25 19:59:29 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Fri, 25 Jan 2019 11:59:29 -0800
Subject: <i18n dev> [13] RFR: 8217609: New era placeholder not recognized by
 java.text.SimpleDateFormat
Message-ID: <9dd0ed3d-befc-1302-ac6e-657394cb1717@oracle.com>

Hello,

Please review the fix to the following issue:

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

The proposed changeset is located at:

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

Although the behavior described in the issue is the expected one (i.e., 
CLDR currently does not provide names for the new era), supplementing 
the name in the CLDR data is desirable from the user's point of view.

Naoto

From nishit.jain at oracle.com  Tue Jan 29 11:04:50 2019
From: nishit.jain at oracle.com (Nishit Jain)
Date: Tue, 29 Jan 2019 16:34:50 +0530
Subject: <i18n dev> [13] RFR: 8217609: New era placeholder not
 recognized by java.text.SimpleDateFormat
In-Reply-To: <9dd0ed3d-befc-1302-ac6e-657394cb1717@oracle.com>
References: <9dd0ed3d-befc-1302-ac6e-657394cb1717@oracle.com>
Message-ID: <2eaebb3f-8076-411d-e724-e8168b7ffa1a@oracle.com>

Hi Naoto,

Look good to me.

Regards,
Nishit Jain
On 26-01-2019 01:29, naoto.sato at oracle.com wrote:
> Hello,
>
> Please review the fix to the following issue:
>
> https://bugs.openjdk.java.net/browse/JDK-8217609
>
> The proposed changeset is located at:
>
> http://cr.openjdk.java.net/~naoto/8217609/webrev.00/
>
> Although the behavior described in the issue is the expected one 
> (i.e., CLDR currently does not provide names for the new era), 
> supplementing the name in the CLDR data is desirable from the user's 
> point of view.
>
> Naoto


From Sergey.Bylokhov at oracle.com  Tue Jan 29 18:48:11 2019
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 29 Jan 2019 10:48:11 -0800
Subject: <i18n dev> <AWT Dev> RFR: X11 default visual support for IM
 status window on VNC
In-Reply-To: <d856f0b2b5699f693dfb8786fbbd453d@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>
 <5B2A6160.5000107@oracle.com>
 <674fa1d548764758a051953ce9a97d95@linux.vnet.ibm.com>
 <47596f79d10fcfac856172db4d8cffd2@linux.vnet.ibm.com>
 <533c8ab5-31d9-58bd-4250-03e1c24f6f23@oracle.com>
 <d856f0b2b5699f693dfb8786fbbd453d@linux.vnet.ibm.com>
Message-ID: <e12022f3-8ba9-0d18-66b0-6558883c600d@oracle.com>

Looks fine, if there are no other comments I'll push the fix this week.


On 21/01/2019 20:08, Ichiroh Takiguchi wrote:
> Hello Sergey.
> 
> Sorry, code conflict was there.
> I fixed code conflict and modified Copyright year.
> 
> Could you review the fix again ?
> 
> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8212677
> Change: https://cr.openjdk.java.net/~itakiguchi/8212677/webrev.01/
> 
> Thanks,
> Ichiroh Takiguchi
> IBM Japan, Ltd.
> 
> On 2018-12-01 09:49, Sergey Bylokhov wrote:
>> Looks fine, if there are no other comments I'll push the fix.
>>
>> On 26/11/2018 05:02, Ichiroh Takiguchi wrote:
>>> Hello.
>>>
>>> Could you review the fix ?
>>>
>>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8212677
>>> Change: https://cr.openjdk.java.net/~itakiguchi/8212677/webrev.00/
>>>
>>> Screen shots are in JDK-8212677.
>>>
>>> I'd like to obtain a sponsor for this issue.
>>>
>>> Thanks,
>>> Ichiroh Takiguchi
>>> IBM Japan, Ltd.
>>>
>>> On 2018-06-21 21:58, Ichiroh Takiguchi wrote:
>>>> 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.
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>
>>>
> 


-- 
Best regards, Sergey.

From naoto.sato at oracle.com  Thu Jan 31 00:35:59 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Wed, 30 Jan 2019 16:35:59 -0800
Subject: <i18n dev> [12] RFR: 8216546: Support new Japanese era in
 java.lang.Character for Java SE 11
Message-ID: <9326b86b-9bb0-af33-3d64-b33aab9fa635@oracle.com>

Hi,

Please review the javadoc fix for the following issue:

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

The CSR and the proposed changeset are located at:

https://bugs.openjdk.java.net/browse/JDK-8217938
http://cr.openjdk.java.net/~naoto/8216546/webrev.00/

This is a forward poring of the fix made in 11u release:
https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/c1e1669edace

The changeset has been modified from the original 11u one, in order to 
mandate the Japanese Era code point in all Java SE 12 implementations.

Naoto

From naoto.sato at oracle.com  Thu Jan 31 00:51:22 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Wed, 30 Jan 2019 16:51:22 -0800
Subject: <i18n dev> [12] RFR: 8217892: Clarify the support for the new
 Japanese era in java.time.chrono.JapaneseEra
Message-ID: <f93c49ad-72cb-301f-4002-23004c1a876d@oracle.com>

Hi,

Please review the javadoc fix for the following issue:

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

The CSR and the proposed changeset are located at:

https://bugs.openjdk.java.net/browse/JDK-8217939
http://cr.openjdk.java.net/~naoto/8217892/webrev.00/

This is a (effective) forward poring of the fix made in 11u release:
https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/75672ce3d004

Naoto

From chris.hegarty at oracle.com  Thu Jan 31 09:15:32 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 31 Jan 2019 09:15:32 +0000
Subject: <i18n dev> [12] RFR: 8216546: Support new Japanese era in
 java.lang.Character for Java SE 11
In-Reply-To: <9326b86b-9bb0-af33-3d64-b33aab9fa635@oracle.com>
References: <9326b86b-9bb0-af33-3d64-b33aab9fa635@oracle.com>
Message-ID: <1C051A2D-A845-4C6E-A437-9BDA5FBCDF44@oracle.com>

Naoto,

> On 31 Jan 2019, at 00:35, naoto.sato at oracle.com wrote:
> 
> ...
> 
> https://bugs.openjdk.java.net/browse/JDK-8217938
> http://cr.openjdk.java.net/~naoto/8216546/webrev.00/

This looks good. Just a few very minor comments.

1) To be consistent can you please include the addition of the
  word ?conditions? to the following methods:

    ?... the following *conditions* is true:"

     isJavaIdentifierPart(char ch)
     isJavaIdentifierPart(int codePoint) 
     isJavaLetter(char ch) 
     isJavaIdentifierPart(char)

2)  There was a small correction in isJavaIdentifierPart(int). 

    Replace    "the character"  with   "the code point"

Thanks,
-Chris.


From chris.hegarty at oracle.com  Thu Jan 31 09:19:06 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 31 Jan 2019 09:19:06 +0000
Subject: <i18n dev> [12] RFR: 8217892: Clarify the support for the new
 Japanese era in java.time.chrono.JapaneseEra
In-Reply-To: <f93c49ad-72cb-301f-4002-23004c1a876d@oracle.com>
References: <f93c49ad-72cb-301f-4002-23004c1a876d@oracle.com>
Message-ID: <88BA937B-34E9-4E58-9A27-5E4864C8F133@oracle.com>

Naoto,

> On 31 Jan 2019, at 00:51, naoto.sato at oracle.com wrote:
> 
> ..
> https://bugs.openjdk.java.net/browse/JDK-8217939
> http://cr.openjdk.java.net/~naoto/8217892/webrev.00/

The changes look good. Reviewed.

-Chris.

From naoto.sato at oracle.com  Thu Jan 31 17:07:45 2019
From: naoto.sato at oracle.com (Naoto Sato)
Date: Thu, 31 Jan 2019 09:07:45 -0800
Subject: <i18n dev> [12] RFR: 8216546: Support new Japanese era in
 java.lang.Character for Java SE 11
In-Reply-To: <1C051A2D-A845-4C6E-A437-9BDA5FBCDF44@oracle.com>
References: <9326b86b-9bb0-af33-3d64-b33aab9fa635@oracle.com>
 <1C051A2D-A845-4C6E-A437-9BDA5FBCDF44@oracle.com>
Message-ID: <411f50b4-1775-fbc6-bc24-3498ea9d85e1@oracle.com>

Hi Chris,

Thank you for the comments. I updated the CSR and the webrev:

https://bugs.openjdk.java.net/browse/JDK-8217938
https://cr.openjdk.java.net/~naoto/8216546/webrev.01/

Naoto

On 1/31/19 1:15 AM, Chris Hegarty wrote:
> Naoto,
> 
>> On 31 Jan 2019, at 00:35, naoto.sato at oracle.com wrote:
>>
>> ...
>>
>> https://bugs.openjdk.java.net/browse/JDK-8217938
>> http://cr.openjdk.java.net/~naoto/8216546/webrev.00/
> 
> This looks good. Just a few very minor comments.
> 
> 1) To be consistent can you please include the addition of the
>    word ?conditions? to the following methods:
> 
>      ?... the following *conditions* is true:"
> 
>       isJavaIdentifierPart(char ch)
>       isJavaIdentifierPart(int codePoint)
>       isJavaLetter(char ch)
>       isJavaIdentifierPart(char)
> 
> 2)  There was a small correction in isJavaIdentifierPart(int).
> 
>      Replace    "the character"  with   "the code point"
> 
> Thanks,
> -Chris.
> 

From chris.hegarty at oracle.com  Thu Jan 31 17:36:12 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 31 Jan 2019 17:36:12 +0000
Subject: <i18n dev> [12] RFR: 8216546: Support new Japanese era in
 java.lang.Character for Java SE 11
In-Reply-To: <411f50b4-1775-fbc6-bc24-3498ea9d85e1@oracle.com>
References: <9326b86b-9bb0-af33-3d64-b33aab9fa635@oracle.com>
 <1C051A2D-A845-4C6E-A437-9BDA5FBCDF44@oracle.com>
 <411f50b4-1775-fbc6-bc24-3498ea9d85e1@oracle.com>
Message-ID: <E5755C2D-D94F-448E-9AC8-53F3C22F07CE@oracle.com>



> On 31 Jan 2019, at 17:07, Naoto Sato <naoto.sato at oracle.com> wrote:
> 
> Hi Chris,
> 
> Thank you for the comments. I updated the CSR and the webrev:
> 
> https://bugs.openjdk.java.net/browse/JDK-8217938
> https://cr.openjdk.java.net/~naoto/8216546/webrev.01/

Thanks Naoto. Reviewed.

-Chris