RFR 8158880: java/time/tck/java/time/format/TCKDateTimeFormatterBuilder.java fail with zh_CN locale

[Roger Riggs]

Hi,

I agree, using toFormatter(Locale.US) is best.  It avoids even transient 
changes to the default locale.

(BTW, An exception in the test would fail to restore the locale unless 
it was in a try{} finally{} and
someday multiple tests might be run concurrently in the same vm.)

Roger


On 11/11/2016 3:39 AM, nadeesh tv wrote:
> Hi Bhanu,
>
>
> I think adding Locale to the formatter will be better
>
> For eg:
>
> DateTimeFormatter f = 
> builder.parseLenient().appendValue(HOUR_OF_DAY).appendValue(MINUTE_OF_HOUR, 
> 2).appendLiteral('9').toFormatter(Locale.UK);
>
> Since other test cases use Locale.UK may be here also you can use UK 
> instead of locale.US.
>
> Thanks and Regards,
> Nadeesh
>
>
> On 11/11/2016 10:57 AM, Bhanu Gopularam wrote:
>> Hi Roger,
>>
>>
>> Thanks for the review. I have updated the test to set default locale 
>> (and restore it) in only those methods which were causing problem in 
>> non English locales.
>>
>>
>> Please review the updated webrev below:
>>
>> Webrev: http://cr.openjdk.java.net/~bgopularam/JDK-8158880/webrev.01/
>>
>>
>> Thanks,
>>
>> Bhanu
>>
>>
>> From: Roger Riggs
>> Sent: Tuesday, June 21, 2016 8:36 PM
>> To: Bhanu Gopularam; core-libs-dev at openjdk.java.net
>> Cc: Stephen Colebourne
>> Subject: Re: RFR 8158880: 
>> java/time/tck/java/time/format/TCKDateTimeFormatterBuilder.java fail 
>> with zh_CN locale
>>
>>
>> Hi Bhanu,
>>
>> It can be problematic to change the default Locale for the entire 
>> process, especially
>> since many tests are run in the same process.  It would be preferable 
>> to set the locale
>> in the DateTimeFormatter builder instead of changing the process wide 
>> Locale.
>>
>> Please identify the specific test case to apply the fix only where 
>> needed.
>>
>> Is it only 
>> tck.java.time.format.TCKDateTimeFormatterBuilder.test_appendZoneText_parseGenericTimeZonePatterns
>> where the failure is seen?
>>
>> This would be an issue testing any pattern letter with locale 
>> dependent behavior.
>> The locale should be set explicitly in the test.
>>
>> BTW,  There is a predefined Locale.US that can be used, no need to 
>> construct a new Locale.
>>
>> Roger
>>
>>
>>
>> On 6/21/2016 6:31 AM, Bhanu Gopularam wrote:
>>
>> Hi all,
>>   May I request you to review fix for following issue
>> Bug id: https://bugs.openjdk.java.net/browse/JDK-8158880
>>   Solution: To avoid test failure in non english locales, set the 
>> default locale while initial test setup
>>   Webrev: http://cr.openjdk.java.net/~bgopularam/JDK-8158880/webrev.00/
>>   Thanks,
>> Bhanu
>>
>