JDK-7168528 : LocaleServiceProvider needs to be aware of Locale extensions
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.util:i18n
  • Affected Version: 7
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2012-05-14
  • Updated: 2017-05-17
  • Resolved: 2012-09-05
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
8 b55Fixed
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.

Run the new test developed for JEP 127 with latest JPRT build and JDK8 b62.

SUGGESTED FIX http://hg.openjdk.java.net/jdk8/tl/jdk/rev/131a683a2ce0

EVALUATION The fix will be to add a new method to LocaleServiceProvider.isSupportedLocale(Locale) so that a provider can determine if it can support the given locale.