<i18n dev> [8] RFR: 8013233, java/util/Locale/LocaleProviders.sh fails

Naoto Sato naoto.sato at oracle.com
Wed May 15 13:55:49 PDT 2013


I initially thought the case only for result==null && expected!=null, 
but your test looks better. Here is the modified webrev, with the 
variable name "expected" replaced with "hostResult" to avoid confusion.

http://cr.openjdk.java.net/~naoto/8013233/webrev.02/

Naoto

On 5/14/13 9:22 PM, Masayoshi Okutsu wrote:
> Do you mean this?
>
>          if (result == null ||
>              expected != null &&
>              !result.equals(expected)) {
>                  throw new RuntimeException(...);
>          }
>
> Masayoshi
>
> On 5/15/2013 1:06 AM, Naoto Sato wrote:
>> Well, I just want to make sure that, in case of expected == null, the
>> result value still is non null, which assures that FALLBACK provider
>> has kicked in. So I think checking "result != null" is still needed.
>>
>> Naoto
>>
>> On 5/13/13 5:15 PM, Masayoshi Okutsu wrote:
>>> I see. The test case should get the expected value first, then. If
>>> expected == null, skip the test case (no need to get the result value)?
>>>
>>> Masayoshi
>>>
>>> On 5/14/2013 4:21 AM, Naoto Sato wrote:
>>>> Actually, the bug itself is the case that Objects.equals(result,
>>>> expected) would fail. Since on that machine, result="mk" and
>>>> expected=(null) where fallback kicks in. Maybe the variable name
>>>> "expected" be replaced with something like "resultFromHOST", but the
>>>> test itself cannot just use Objects.equals().
>>>>
>>>> Naoto
>>>>
>>>> On 5/12/13 10:21 PM, Masayoshi Okutsu wrote:
>>>>> I think Objects.equals(Object, Object) should be used when comparing
>>>>> result and expected. Otherwise, the fix looks OK to me.
>>>>>
>>>>> Masayoshi
>>>>>
>>>>> On 5/8/2013 7:10 AM, Naoto Sato wrote:
>>>>>> On 5/6/13 9:30 PM, Masayoshi Okutsu wrote:
>>>>>>> Not sure how the test can detect bugs in the provider of the host
>>>>>>> adapter.
>>>>>>
>>>>>> The test case only checks the Java side code paths, i.e., whether the
>>>>>> returned display name from the HOST adapter is honored over JRE's one
>>>>>> or not. In the case of "mk", that detects the failure.
>>>>>>
>>>>>>> BTW, some lines are very long requiring a wide screen monitor.
>>>>>>
>>>>>> Fixed: http://cr.openjdk.java.net/~naoto/8013233/webrev.01/
>>>>>>
>>>>>> Naoto
>>>>>>
>>>>>>>
>>>>>>> Masayoshi
>>>>>>>
>>>>>>> On 5/7/2013 3:50 AM, Naoto Sato wrote:
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> Please review the following changeset:
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~naoto/8013233/webrev.00/
>>>>>>>>
>>>>>>>> for the following bug:
>>>>>>>>
>>>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8013233
>>>>>>>>
>>>>>>>> The original test case assumed Windows ver 6.0 or upper always
>>>>>>>> contain
>>>>>>>> the localized display name for Macedonian, which wasn't the case in
>>>>>>>> some installation. Removed the hard coded name and replaced them
>>>>>>>> with
>>>>>>>> the actual returned name from the host adapter.
>>>>>>>>
>>>>>>>> Naoto
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>



More information about the i18n-dev mailing list