[13] RFR: 8220224: With CLDR provider, NumberFormat.format could not handle locale with number extension correctly.

[Joseph D. Darcy]

PS Looking more closely, I see the the <code> issue is addressed in the 
01 version of the webrev; I was only looking at the 00 version before :-)

Thanks,

-Joe

On 3/21/2019 2:11 PM, Joseph D. Darcy wrote:
> Hi Naoto,
>
> Looks okay. The serial-related declarations are still using 
> <code></code>; I think it is fine to push what you have now, but what 
> encourage a follow-up bug to replace <code>foo</code> with {@code foo} 
> throughout the entire class.
>
> Thanks,
>
> -Joe
>
> On 3/21/2019 1:54 PM, Naoto Sato wrote:
>> Hello,
>>
>> Please review the fix to the following issue:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8220224
>>
>> Here is the CSR and proposed changeset:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8220728
>> http://cr.openjdk.java.net/~naoto/8220224/webrev.01/
>>
>> DecimalFormatSymbols assumes minus/percent/permille as a single 
>> character, which is not capable of supporting ones for BiDi languages 
>> that involve BiDi formatting characters. With this fix, 
>> DecimalFormatSymbols uses String variants of symbols from CLDR, and 
>> retains them for serialization.
>>
>> The above webrev contains <code> tag cleanup which was suggested in 
>> the CSR. The following webrev only contains relevant changes to the 
>> issue (excluding those <code> cleanup):
>>
>> http://cr.openjdk.java.net/~naoto/8220224/webrev.00/
>>
>> Naoto
>