[loc-en-dev] Equality of base locale and LocaleServiceProvider implementation

[Naoto Sato]

Umaoka-san,

I don't think this is a compatibility issue, because the existing SPI 
implementations should still work compatible with the locales without 
extensions.  Possible issue would only arise with the new locales.

BTW, current SPI implementation invocation already involves fallback 
itself. i.e., say the request locale is xx_YY_foo_bar, and one SPI 
provider implements xx_YY, then that provider's service is used.  So 
adding the extension fallback is not that ugly to me.

Thanks,
Naoto

Yoshito Umaoka wrote:
> Hi folks
> 
> The very first proposal suggested that locale service look up is done by 
> base locale, then a service provider may or may not use information 
> taken from extensions.  For example, NumberFormat#getInstance(Locale) 
> look for a NumberFormatServiceProvider implementation which support the 
> Locale if the support is not available in JDK.  The set of Locales 
> supported by a LocaleServiceProvider is resolved by an array of Locales 
> returned by getAvailableLocales implemented by each provider.  In this 
> scenario, the original design proposal suggested to compare a Locale 
> returned by getAvailableLocales with the requested Locale only for the 
> base locale portion (language, script, region and variant).  We did not 
> look into this area in detail, because we tried to wrap up the APIs in 
> Locale itself first.  I noticed there is a potential problem in this 
> scenario.  The existing LocaleServiceProvider implementations do not 
> know about the extensions.  If you have two Locales with the same base 
> locale, but one with no extensions, another with LDML extensions such as 
> nu=arab (number system is Arabic).  For these two Locales, 
> localeA.equals(localeB) returns false, because they are different.  If 
> an existing LocaleServiceProvider implementation depends on 
> Locale#equals, it may not work as expected (I thing it's not practical, 
> but possible...)  Of course, even a LocaleServiceProvider return null, 
> it does not cause any disaster (because it's the contract - for Locale 
> which cannot be handled by a LocaleServicePoriver implementation, it can 
> return null, then JDK has a fallback logic.)
> 
> First of all, do we care this potential compatibility problem?  This 
> happens - if someone request a Locale with an extension and if the 
> Locale is not supported by JDK and if its base locale is supported by a 
> custom SPI implementation and if the SPI implementation depends on 
> Locale#equals to identify a Locale..  Even those ifs are all true, it 
> still return a service object (but fallback is involved).
> 
> If we think we cannot break this, then, we still have several options.
> 
> Option 1: If a LocaleServiceProvider claims that the requested Locale's 
> base locale is supported, then, JDK calls the provider implementation 
> with full Locale (including extensions).  If it returns null, JDK tries 
> the requested Locale's base locale only.
> Option 2: Add parallel APIs in SPI - for example, in addition to 
> NumberFormatProvider#getNumberInstance(Locale), add a method 
> NumberFormatProvider#getNumberInstanceEx(Locale).  JDK calls "Ex" 
> version with extension (the default implementation is to return null), 
> then if it returns null, call regular version without extensions.
> 
> Well, these are somewhat ugly.  So if possible, I'd like to ignore this 
> potential compatibility issue.  Do you have any opinions?
> 
> While thinking various scenarios, I'm feeling that we should provide an 
> easy way to compare two locales excluding exceptions.  I proposed 
> getBaseLocale before because I thought it might have a good use case.  
> I'm considering such API again.  Actually, 
> Locale#hasSameBaseLocale(Locale) would do for this purpose (do not need 
> to create a Locale).
> 
> 
> Thanks,
> Yoshito


-- 
Naoto Sato