Start line:  
End line:  

Snippet Preview

Snippet HTML Code

Stack Overflow Questions
I'm working on an international project and have observed that, in Java, the choice of the decimal separator is based on the Locale's language, not its country. For example: DecimalFormat currencyFormatter = (DecimalFormat) NumberFormat.getInstance(new Locale("it","IT")); System.out.println(currencyFormatter.format(-123456.78)); currencyFormatter = (DecimalFormat) NumberFormat.getInstance(new...
Recently Sun/Oracle changed currency code for Ukrainian hrivna to incorrect one and I've to fix that in my code. I find out that Java 6 should allows me to do that at Java level (details are here) via CurrencyNameProvider (see also). Unfortunately I don't understand which locales should return method public Locale[] getAvailableLocales() {} Any working examples are welcome!
Is there any away to configure the pattern for String values returned by DateFormat's getDateInstance(), for each style - SHORT, MEDIUM, LONG, and FULL? For example, DateFormat.getDateInstance(DateFormat.MEDIUM, Locale.US) will always return a value something like Jan 12, 1952. How can I have this return 1952, Jan 12?
  /*
   * Copyright 2005-2006 Sun Microsystems, Inc.  All Rights Reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
   * under the terms of the GNU General Public License version 2 only, as
   * published by the Free Software Foundation.  Sun designates this
   * particular file as subject to the "Classpath" exception as provided
   * by Sun in the LICENSE file that accompanied this code.
  *
  * This code is distributed in the hope that it will be useful, but WITHOUT
  * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
  * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
  * version 2 for more details (a copy is included in the LICENSE file that
  * accompanied this code).
  *
  * You should have received a copy of the GNU General Public License version
  * 2 along with this work; if not, write to the Free Software Foundation,
  * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
  *
  * Please contact Sun Microsystems, Inc., 4150 Network Circle, Santa Clara,
  * CA 95054 USA or visit www.sun.com if you need additional information or
  * have any questions.
  */
 
 package java.util.spi;
 

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 '#' ('\u0023'); 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 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. If neither the Java runtime environment itself nor an installed provider supports the requested locale, a fallback locale is constructed by replacing the first of the variant, country, or language strings of the locale that's not an empty string with an empty string, and the lookup process is restarted. In the case that the variant contains one or more '_'s, the fallback locale is constructed by replacing the variant with a new variant which eliminates the last '_' and the part following it. Even if a fallback occurs, methods that return requested objects or name are invoked with the original locale before the fallback.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.

Since:
1.6
public abstract class LocaleServiceProvider {

    
Sole constructor. (For invocation by subclass constructors, typically implicit.)
    protected LocaleServiceProvider() {
    }

    
Returns an array of all locales for which this locale service provider can provide localized objects or names.

Returns:
An array of all locales for which this locale service provider can provide localized objects or names.
    public abstract Locale[] getAvailableLocales();
New to GrepCode? Check out our FAQ X