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
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
- Time zone names for the
- Symbols for the
Each of the classes mentioned above now has a corresponding abstract provider
class in the
java.text.spi package. Concrete provider classes
advertise the locales they support through their
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
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.