An abstract class for service providers that provide locale-dependent Calendar parameters.

Field
Value
Description


Calendar.MONTH
Calendar.JANUARY to Calendar.UNDECIMBER
Month numbering is 0-based (e.g., 0 - January, ..., 11 -
    December). Some calendar systems have 13 months. Month
    names need to be supported in both the formatting and
    stand-alone forms if required by the supported locales. If there's
    no distinction in the two forms, the same names should be returned
    in both of the forms.


Calendar.DAY_OF_WEEK
Calendar.SUNDAY to Calendar.SATURDAY
Day-of-week numbering is 1-based starting from Sunday (i.e., 1 - Sunday,
    ..., 7 - Saturday).


Calendar.AM_PM
Calendar.AM to Calendar.PM
0 - AM, 1 - PM

Calendar Type
Field
Value
Description


"gregory"
Calendar.ERA
0
GregorianCalendar.BC (BCE)


1
GregorianCalendar.AD (CE)


"buddhist"
Calendar.ERA
0
BC (BCE)


1
B.E. (Buddhist Era)


"japanese"
Calendar.ERA
0
Seireki (Before Meiji)


1
Meiji


2
Taisho


3
Showa


4
Heisei


Calendar.YEAR
1
the first year in each era. It should be returned when a long
style (Calendar.LONG_FORMAT or Calendar.LONG_STANDALONE) is
specified. See also the
Year representation in SimpleDateFormat.


"roc"
Calendar.ERA
0
Before R.O.C.


1
R.O.C.


"islamic"
Calendar.ERA
0
Before AH


1
Anno Hijrah (AH)

An abstract class for service providers that provide localized string
representations (display names) of Calendar field values.

Calendar Types

Calendar types are used to specify calendar systems for which the getDisplayName and getDisplayNames methods provide
calendar field value names. See Calendar.getCalendarType() for details.

Calendar Fields

Calendar fields are specified with the constants defined in Calendar. The following are calendar-common fields and their values to be
supported for each calendar system.



    Field
    Value
    Description


    Calendar.MONTH
    Calendar.JANUARY to Calendar.UNDECIMBER
    Month numbering is 0-based (e.g., 0 - January, ..., 11 -
        December). Some calendar systems have 13 months. Month
        names need to be supported in both the formatting and
        stand-alone forms if required by the supported locales. If there's
        no distinction in the two forms, the same names should be returned
        in both of the forms.


    Calendar.DAY_OF_WEEK
    Calendar.SUNDAY to Calendar.SATURDAY
    Day-of-week numbering is 1-based starting from Sunday (i.e., 1 - Sunday,
        ..., 7 - Saturday).


    Calendar.AM_PM
    Calendar.AM to Calendar.PM
    0 - AM, 1 - PM



The following are calendar-specific fields and their values to be supported.



    Calendar Type
    Field
    Value
    Description


    "gregory"
    Calendar.ERA
    0
    GregorianCalendar.BC (BCE)


    1
    GregorianCalendar.AD (CE)


    "buddhist"
    Calendar.ERA
    0
    BC (BCE)


    1
    B.E. (Buddhist Era)


    "japanese"
    Calendar.ERA
    0
    Seireki (Before Meiji)


    1
    Meiji


    2
    Taisho


    3
    Showa


    4
    Heisei


    Calendar.YEAR
    1
    the first year in each era. It should be returned when a long
    style (Calendar.LONG_FORMAT or Calendar.LONG_STANDALONE) is
    specified. See also the
    Year representation in SimpleDateFormat.


    "roc"
    Calendar.ERA
    0
    Before R.O.C.


    1
    R.O.C.


    "islamic"
    Calendar.ERA
    0
    Before AH


    1
    Anno Hijrah (AH)



Calendar field value names for "gregory" must be consistent with
the date-time symbols provided by DateFormatSymbolsProvider.

Time zone names are supported by TimeZoneNameProvider.

An abstract class for service providers that
provide localized currency symbols and display names for the
Currency class.
Note that currency symbols are considered names when determining
behaviors described in the
LocaleServiceProvider
specification.

An abstract class for service providers that
provide localized names for the
Locale class.

 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.text
and 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.text and
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.

Packaging of Locale Sensitive Service Provider Implementations
Implementations of these locale sensitive services are packaged using the
Java Extension Mechanism
as installed extensions.  A provider identifies itself with a
provider-configuration file in the resource directory META-INF/services,
using the fully qualified provider interface class name as the file name.
The file should contain a list of fully-qualified concrete provider class names,
one per line. A line is terminated by any one of a line feed ('\n'), a carriage
return ('\r'), or a carriage return followed immediately by a line feed. Space
and tab characters surrounding each name, as well as blank lines, are ignored.
The comment character is '#' ('#'); on each line all characters following
the first comment character are ignored. The file must be encoded in UTF-8.

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.DateFormatProvider
And the file java.text.spi.DateFormatProvider should have
a line such as:


com.foo.DateFormatProviderImpl
which is the fully qualified class name of the class implementing
DateFormatProvider.
Invocation of Locale Sensitive Services

Locale sensitive factory methods and methods for name retrieval in the
java.text and 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 isSupportedLocale
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 by default. (If locale's extensions should
also be checked, the isSupportedLocale method must be overridden.)
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 ResourceBundle by default (see
getCandidateLocales
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 Locale 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.

Starting from JDK8, the search order of locale sensitive services can
be configured by using the "java.locale.providers" system property.
This system property declares the user's preferred order for looking up
the locale sensitive services separated by a comma. It is only read at
the Java runtime startup, so the later call to System.setProperty() won't
affect the order.

For example, if the following is specified in the property:


java.locale.providers=SPI,JRE
where "SPI" represents the locale sensitive services implemented in the
installed SPI providers, and "JRE" represents the locale sensitive services
in the Java Runtime Environment, the locale sensitive services in the SPI
providers are looked up first.

There are two other possible locale sensitive service providers, i.e., "CLDR"
which is a provider based on Unicode Consortium's
CLDR Project, and "HOST" which is a
provider that reflects the user's custom settings in the underlying operating
system. These two providers may not be available, depending on the Java Runtime
Environment implementation. Specifying "JRE,SPI" is identical to the default
behavior, which is compatibile with the prior releases.

An interface for service providers that provide implementations of ResourceBundle.Control. The default resource bundle loading
behavior of the ResourceBundle.getBundle factory methods that take
no ResourceBundle.Control instance can be modified with ResourceBundleControlProvider implementations.

Provider implementations must be packaged using the Java Extension
Mechanism as installed extensions. Refer to ServiceLoader
for the extension packaging. Any installed ResourceBundleControlProvider implementations are loaded using ServiceLoader at the ResourceBundle class loading time.

An abstract class for service providers that
provide localized time zone names for the
TimeZone class.
The localized time zone names available from the implementations of
this class are also the source for the
DateFormatSymbols.getZoneStrings() method.