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

[Yoshito Umaoka]

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