You can create a Locale with any combination of valid language and country codes, but that doesn't mean that you can use it. Remember, a Locale object is only an identifier. You pass the Locale object to other objects, which then do the real work. These other objects, which we call locale-sensitive, do not know how to deal with all possible Locale definitions.

To find out which types of Locale definitions a locale-sensitive class recognizes, you invoke the getAvailableLocales method. For example, to find out which Locale definitions are supported by the DateFormat class, you could write a routine such as the following:

import java.util.*;
import java.text.*;

public class Available {
    static public void main(String[] args) {
	Locale list[] = DateFormat.getAvailableLocales();
	for (Locale aLocale : list) {
	    System.out.println(aLocale.toString());
	}
    }
}

Note that the String returned by toString contains the language and country codes, separated by an underscore:

ar_EG
be_BY
bg_BG
ca_ES
cs_CZ
da_DK
de_DE
.
.
.

If you want to display a list of Locale names to end users, you should show them something easier to understand than the language and country codes returned by toString. Instead you can invoke the Locale.getDisplayName method, which retrieves a localized String of a Locale object. For example, when toString is replaced by getDisplayName in the preceding code, the program prints the following lines:

Arabic (Egypt)
Belarussian (Belarus)
Bulgarian (Bulgaria)
Catalan (Spain)
Czech (Czech Republic)
Danish (Denmark)
German (Germany)
.
.
.

You may see different locale lists depending on the Java Platform implementations.