Liking cljdoc? Tell your friends :D

jdk.util.spi.CalendarDataProvider

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

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

jdk.util.spi.CalendarNameProvider

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 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.
raw docstring

jdk.util.spi.core

No vars found in this namespace.

jdk.util.spi.CurrencyNameProvider

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 currency symbols and display names for the
Currency class.
Note that currency symbols are considered names when determining
behaviors described in the
LocaleServiceProvider
specification.
raw docstring

jdk.util.spi.LocaleNameProvider

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

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

jdk.util.spi.LocaleServiceProvider

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 (' '), a carriage return (' '), 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.

 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 ('
'), a carriage
  return ('
'), 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.
raw docstring

jdk.util.spi.ResourceBundleControlProvider

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 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.
raw docstring

jdk.util.spi.TimeZoneNameProvider

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.

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.
raw docstring

cljdoc is a website building & hosting documentation for Clojure/Script libraries

× close