The locale service provider SPI should be aware of Locale extensions. The concrete issues are:

- The current locale service provider look-up mechanism uses the LocaleServiceProvider.getAvailableLocales() value which excludes Locale extensions. Therefore, some mismatches between expectations and actual services could happen. For example, if the requested locale is "ja-JP-u-ca-japanese" (in the language tag form), the look-up uses only the "ja-JP" part and, therefore, the selected provider may not be capable of supporting the Japanese imperial calendar, such as Imperial era names.

- Each LocaleServiceProvier subclass should mention what Locale extensions may be requested. Otherwise, provider implementers can't deal with expected extensions. For example, DecimalFormatSymbolsProvider needs to provide support of different numeric systems, such as "ar-u-nu-arab" (Arabic with Arabic-Indic digits) and "ar-u-nu-latn" (Arabic with Latin digits).

In addition, the Locale class should add more support for extensions. The specific ones are:

- Locale.hasExtensions() - returns true if this Locale has any extensions.

- Locale.stripExtensions() - returns a copy of this Locale with no extensions.