[loc-en-dev] ResourceBundle lookup candidate list and inheritance

[Doug Felt]

On Wed, Jul 21, 2010 at 2:59 AM, Masayoshi Okutsu <
masayoshi.okutsu at oracle.com> wrote:

>  On 7/21/2010 11:17 AM, Doug Felt wrote:
>
>> ResourceBundle.getBundle(String, Locale, ClassLoader) currently says that
>> the parent chain of a bundle is formed by truncation.
>>
>
> That's the default behavior. But it can be modified using
> ListResourceBundle even before JDK6.
>
>
>   The implementation uses ResourceBundle.Control.INSTANCE which uses
>> truncation in getCandidateLocales().
>>
>
> The default ResourceBundle.Control implementation provides the default
> getBundle behavior. But developers can change the getBundle behavior using
> another ResourceBundle.Control implementation.
>
> So, why did it sound broken?
>
> It seems there's no way that someone wanting to implement Control to
generate a more complex lookup path could get the simple truncation behavior
for the parent path, since the same list of locales is used for both. Maybe
though that's for the best.

>
>  We've been proposing that the default implementation of
>> ResourceBundle.Control special case getCandidateLocales for some Norwegian
>> and Chinese locales, so that both legacy and new Locales can access either
>> legacy or new resource data.  This is documented in the locale enhancement
>> notes, see
>> http://sites.google.com/site/openjdklocale/design-notes/resource-bundle-lookup-order
>>
>
> That is what we (actually Naoto) tried to do for the Hebew and Norwegian
> support issues (4778440 and 5005601) in JDK6, but we gave up the change due
> to a bug report complaining a known compatibility restriction. The
> compatibility issue was in the Locale class change, though.
>
>
>  This would imply that ResourceBundle.getBundle(String, Locale,
>> ClassLoader) cannot use the control-based implementation since the parent
>> chain would not match the candidate locale list generated by
>> getCandidateLocales.  How would you resolve this?
>>
>
> Both the ResourceBundle.getBundle(String, Locale, ClassLoader) spec and the
> ResourceBundle.Control.getCandidateLocales spec will need to be changed. As
> far as the behavior is upward compatible with JDK6, the changes should be
> OK.
>
> Masayoshi
>
> Naoto points out in another thread that  we could document that the Chinese
and Norwegian cases are exceptions and continue to document that truncation
is the default case: "So other than Chinese and Norwegian, I'd expect the
default behavior is still truncation, right? If so, can we just describe
those two cases as special cases in addition to the truncation method? Since
legacy applications don't have those nn/nb/Hans/Hant resource bundles, it'd
still be compatible with prior releases."

However, I'd like to change the documentation of
ResourceBundle.getBundle(String, Locale, ClassLoader) to say simply that it
uses a default instance of ResourceBundle.Control and
calls ResourceBundle.getBundle(String, Locale, ClassLoader,
ResourceBundle.Control), and put the existing (amended) documentation of the
default lookup and parent chain behavior into
ResourceBundle.Control.getCandidateLocales, where it actually resides.  Does
anyone see a problem with that?

Doug

>
>> Doug
>>
>>
>> On Tue, Jul 20, 2010 at 6:45 PM, Masayoshi Okutsu <
>> masayoshi.okutsu at oracle.com <mailto:masayoshi.okutsu at oracle.com>> wrote:
>>
>>    On 7/15/2010 7:26 AM, Doug Felt wrote:
>>
>>>    Is this intended behavior?
>>>
>>
>>    Yes, it is. Please refer to RFE 5102289 which is the umbrella for
>>    all the ResourceBundle enhancements in JDK6.
>>
>>      It sounds broken to me.
>>>
>>
>>    If so, the ResourceBundle API itself has been broken. I believe
>>    that the same thing can be done using ListResourceBundle without
>>    ResourceBundle.Control.
>>
>>    Masayoshi
>>
>>
>>
>>>    Doug
>>>
>>>    On Tue, Jul 13, 2010 at 12:24 PM, Yoshito Umaoka
>>>    <y.umaoka at gmail.com <mailto:y.umaoka at gmail.com>> wrote:
>>>
>>>        For now, Java uses the same list for lookup and inheritance.
>>>
>>>        For example, if you customize the lookup candidate list using
>>>        ResourceBundle.Control and produce locale list like - "fr",
>>>        "de", ROOT, and if all bundles exist, bundle_de will be the
>>>        parent of bundle_fr, root bundle will be the parent of
>>>        bundle_de. In other words, ResourceBundle#getObject(String
>>>        key) will get a resource from bundle_de when the resource is
>>>        missing in bundle_fr, then if it does not exist in bundle_de,
>>>        try the root bundle.
>>>
>>>        We probably cannot change the behavior, so we should consider
>>>        this aspect for designing special lookup order for
>>>        Chinese/Norwegian locales.
>>>
>>>        -Yoshito
>>>
>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/locale-enhancement-dev/attachments/20100721/c3f29a9b/attachment.html