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

Masayoshi Okutsu masayoshi.okutsu at oracle.com
Wed May 15 16:29:39 PDT 2013


Looks good to me.

Masayoshi

On 5/16/2013 5:55 AM, Naoto Sato wrote:
> 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