Locale Sensitive Services SPI

June 27, 2005

OK, the name of this new feature in Java SE 6 has become more complicated than we’d like it to be. What this “Locale Sensitive Services SPI” really means is that third parties can now provide implementations of most locale sensitive classes in the java.text and java.util packages for locales that aren’t yet supported by the Java runtime. “SPI” stands for “service provider interface,” a pattern that some developers are already familiar with from developing character converters, input methods, or other extensions. In this pattern, the Java platform provides interfaces or abstract classes that a developer can implement or subclass. The implementations or subclasses are then packaged with some descriptive information and installed into the Java runtime’s extension directory, and become available to applications through factory methods of the Java platform.

The locale-specific implementations that can be provided through the locale sensitive services SPI are:

• Language and country names for the Locale class
• Time zone names for the TimeZone class
• Symbols for the Currency class
• BreakIterator objects
• Collator objects
• DateFormat objects
• NumberFormat objects
• DateFormatSymbols objects
• DecimalFormatSymbol objects

Each of the classes mentioned above now has a corresponding abstract provider class in the java.util.spi or java.text.spi package. Concrete provider classes advertise the locales they support through their getAvailableLocales methods; these locales get added to the lists returned by the getAvailableLocales methods of the corresponding API classes. If an application requests an object for a locale that the JRE doesn’t support, a provider that supports the locale is asked to provide the necessary object.

An alternative to using an SPI might have been to simply document the format of the resource bundles used in implementing the java.text and java.util packages. This however would have required freezing the current format of the resource bundles, and we weren’t quite ready for that (in fact, we did redesign it for JDK 6). It would also have prevented the implementation of objects such as collators and break iterators that may require locale-specific code or data that doesn’t fit into the existing resource bundle format. Using an SPI gives developers complete freedom in the design of their implementations.

We also considered importing the complete data of the Unicode Consortium’s Common Locale Data Repository instead of providing an SPI. The CLDR covers about twice as many locales as Sun’s current JRE. However, importing the complete CLDR data would have added substantially to the JRE download size while still not helping users of locales that are not (yet) supported in the CLDR. Instead, we only used CLDR for a few additional locales. We think however that it would be worthwhile creating an extension that uses the SPI to support all locales that the CLDR provides but the JRE doesn’t. If you’re interested in helping with such a project, please let us know.