Direct Known Subclasses:
BreakIteratorProvider, DateFormatProvider, DecimalFormatSymbolsProvider, CurrencyNameProvider, NumberFormatProvider, TimeZoneNameProvider, DateFormatSymbolsProvider, CollatorProvider, LocaleNameProvider
This is the super class of all the locale sensitive service provider interfaces (SPIs).
Locale sensitive service provider interfaces are interfaces that
correspond to locale sensitive classes in the
java.util packages. The interfaces enable the
construction of locale sensitive objects and the retrieval of
localized names for these packages. Locale sensitive factory methods
and methods for name retrieval in the
java.util packages use implementations of the provider
interfaces to offer support for locales beyond the set of locales
supported by the Java runtime environment itself.
If a particular concrete provider class is named in more than one configuration file, or is named in the same configuration file more than once, then the duplicates will be ignored. The configuration file naming a particular provider need not be in the same jar file or other distribution unit as the provider itself. The provider must be accessible from the same class loader that was initially queried to locate the configuration file; this is not necessarily the class loader that loaded the file.
For example, an implementation of the DateFormatProvider class should take the form of a jar file which contains the file:
META-INF/services/java.text.spi.DateFormatProviderAnd the file
java.text.spi.DateFormatProvidershould have a line such as:
which is the fully qualified class name of the class implementing
Locale sensitive factory methods and methods for name retrieval in the
java.util packages invoke
service provider methods when needed to support the requested locale.
The methods first check whether the Java runtime environment itself
supports the requested locale, and use its support if available.
Otherwise, they call the
getAvailableLocales() methods of
installed providers for the appropriate interface to find one that
supports the requested locale. If such a provider is found, its other
methods are called to obtain the requested object or name. When checking
whether a locale is supported, the locale's extensions are ignored.
If neither the Java runtime environment itself nor an installed provider
supports the requested locale, the methods go through a list of candidate
locales and repeat the availability check for each until a match is found.
The algorithm used for creating a list of candidate locales is same as
the one used by
ResourceBunlde by default (see
for the details). Even if a locale is resolved from the candidate list,
methods that return requested objects or names are invoked with the original
requested locale including extensions. The Java runtime environment must
support the root locale for all locale sensitive services in order to
guarantee that this process terminates.
Providers of names (but not providers of other objects) are allowed to
return null for some name requests even for locales that they claim to
support by including them in their return value for
getAvailableLocales. Similarly, the Java runtime
environment itself may not have all names for all locales that it
supports. This is because the sets of objects for which names are
requested can be large and vary over time, so that it's not always
feasible to cover them completely. If the Java runtime environment or a
provider returns null instead of a name, the lookup will proceed as
described above as if the locale was not supported.
|Method from java.util.spi.LocaleServiceProvider Summary:|
|Methods from java.lang.Object:|
|clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait|
|Method from java.util.spi.LocaleServiceProvider Detail:|
abstract public Locale getAvailableLocales()
Note: Extensions in a