Re: [13] RFR 8217254, 8217721: CompactNumberFormat​() constructor does not comply with spec and format​() method spec for IAEx is not complaint

[Nishit Jain]

Thanks Naoto,

Updated: http://cr.openjdk.java.net/~nishjain/8217254_8217721/webrev.01/

Regards,
Nishit Jain
On 06-03-2019 23:24, naoto.s...@oracle.com wrote:

Hi Nishit,

Just one comment on j.t.CompactNumberFormat.java. At line 425, Null 
check can be done at the top of the method, as a parameter check, so 
that all the unnecessary "if-elseif" can be avoided. Others look good.


Naoto


On 3/6/19 3:56 AM, Nishit Jain wrote:

Hi,

Please review the fix for JDK-8217254 and JDK-8217721

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

Webrev: http://cr.openjdk.java.net/~nishjain/8217254_8217721/webrev.00/


Issue: The exception thrown by constructor and format() method was 
not compliant with the specification
Fix: Updated the constructor and format method to throw exception as 
per the specification


Regards,
Nishit Jain

Re: [13] RFR: 8218948: SimpleDateFormat :: format - Zone Names are not reflected correctly during run time

[Rachna Goel]

Hi Naoto,

This fix looks good to me.

Thanks,

Rachna


On 3/6/19 4:50 AM, Naoto Sato wrote:

Hello,

Please review the fix to the following issue:

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

The proposed changeset is located at:

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

This is a follow on fix to 8217366. There are several root causes 
included in this bug, when the runtime supplements missing display 
names in non-US locales :-


- Retrieve the names for the requested id first, before it maps to the 
canonical id, and on canonicalizing the id, use unique way 
(canonicalTZID()) to canonicalize.


- Retrieve the names in the same manner, between 
DateFormatSymbols.getZoneStrings() and TimeZone.getDisplayName().


- Correctly map the Chinese locales between JDK and CLDR, in terms of 
Simplified/Traditional scripts.


Naoto


--
Thanks,
Rachna

Re: [13] RFR 8217254, 8217721: CompactNumberFormat​() constructor does not comply with spec and format​() method spec for IAEx is not complaint

[Naoto Sato]

Looks good.

Naoto

On 3/7/19 3:51 AM, Nishit Jain wrote:

Thanks Naoto,

Updated: http://cr.openjdk.java.net/~nishjain/8217254_8217721/webrev.01/

Regards,
Nishit Jain
On 06-03-2019 23:24, naoto.s...@oracle.com wrote:

Hi Nishit,

Just one comment on j.t.CompactNumberFormat.java. At line 425, Null 
check can be done at the top of the method, as a parameter check, so 
that all the unnecessary "if-elseif" can be avoided. Others look good.


Naoto


On 3/6/19 3:56 AM, Nishit Jain wrote:

Hi,

Please review the fix for JDK-8217254 and JDK-8217721

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

Webrev: http://cr.openjdk.java.net/~nishjain/8217254_8217721/webrev.00/


Issue: The exception thrown by constructor and format() method was 
not compliant with the specification
Fix: Updated the constructor and format method to throw exception as 
per the specification


Regards,
Nishit Jain

Re: [13] RFR: 8218948: SimpleDateFormat :: format - Zone Names are not reflected correctly during run time

[Lance Andersen]

Hi Naoto,

Sorry for the late review,  It looks good to me


> On Mar 5, 2019, at 6:20 PM, Naoto Sato  wrote:
> 
> Hello,
> 
> Please review the fix to the following issue:
> 
> https://bugs.openjdk.java.net/browse/JDK-8218948
> 
> The proposed changeset is located at:
> 
> http://cr.openjdk.java.net/~naoto/8218948/webrev.00/
> 
> This is a follow on fix to 8217366. There are several root causes included in 
> this bug, when the runtime supplements missing display names in non-US 
> locales :-
> 
> - Retrieve the names for the requested id first, before it maps to the 
> canonical id, and on canonicalizing the id, use unique way (canonicalTZID()) 
> to canonicalize.
> 
> - Retrieve the names in the same manner, between 
> DateFormatSymbols.getZoneStrings() and TimeZone.getDisplayName().
> 
> - Correctly map the Chinese locales between JDK and CLDR, in terms of 
> Simplified/Traditional scripts.
> 
> Naoto

 
  

 Lance Andersen| 
Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com 

[13] RFR: 8220227: Host Locale Provider getDisplayCountry returns error message under non-English Win10

[Toshio 5 Nakamura]

Hi,

Could you review this fix? I'd like to have a sponsor of it, since I'm an
author.

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

Issue:
Under Windows 10 non-English, Locale.getDisplayCountry() shows an error
message,
if Host Locale Provider is used (-Djava.locale.providers=HOST).

Fix proposal:
The current code compares "Unknown Region (" with the result, but it could
be translated.
I believe we can compare it with "("+RegionCode+")", which covers all 38
Language
Packs of Windows Server 2016.

Thanks,
Toshio Nakamura