クラスLocaleServiceProvider
- 直系の既知のサブクラス:
BreakIteratorProvider
,CalendarDataProvider
,CalendarNameProvider
,CollatorProvider
,CurrencyNameProvider
,DateFormatProvider
,DateFormatSymbolsProvider
,DecimalFormatSymbolsProvider
,LocaleNameProvider
,NumberFormatProvider
,TimeZoneNameProvider
これは、ロケールに依存するすべてのサービス・プロバイダ・インタフェース(SPI)のスーパー・クラスです。
ロケールに依存するサービス・プロバイダ・インタフェースは、各サービスに使用されるロケール・データを提供するために、java.text
およびjava.util
パッケージのロケール依存クラスに対応するインタフェースです。 これらのインタフェースを使えば、これらのパッケージでロケール依存オブジェクトを構築したりローカライズされた名前を取得したりできます。 java.text
およびjava.util
パッケージ内のロケールに依存するファクトリ・メソッドや名前取得メソッドは、プロバイダ・インタフェースの実装を使用することで、Java実行環境自体がサポートする一連のロケールに含まれないロケールをサポートします。
ロケール依存サービス・プロバイダ実装のパッケージ化
これらのロケール依存サービスの実装は、アプリケーションのクラスパスに追加することで利用可能にできます。 各プロバイダは、リソース・ディレクトリMETA-INF/services内のプロバイダ構成ファイルを使ってプロバイダ自体を識別しますが、その際、プロバイダ・インタフェースの完全指定クラス名をファイル名として使用します。 このファイルには、具象プロバイダ・クラスの完全指定名が1行に1つずつ記述されます。 行の終端は、改行('\n')、キャリッジ・リターン('\r')、またはキャリッジ・リターンと改行の組み合わせによって表されます。 それぞれの名前を囲む空白文字とタブ文字、および空白行は無視されます。 コメント文字は「#」(ハッシュ記号)です。各行では、最初のコメント文字以降の文字はすべて無視されます。 ファイルはUTF-8で符号化されている必要があります。特定の具象プロバイダ・クラスが複数の構成ファイル内、または同じ構成ファイル内で繰返し指定されている場合、重複した指定は無視されます。 特定のプロバイダを指定した構成ファイルを、プロバイダ自体と同じJARファイル(またはその他の配布単位)内に含める必要はありません。 このプロバイダには、構成ファイルの検索時に最初に照会されたクラス・ローダーからアクセスできなければいけません。なお、そのクラス・ローダーは、ファイルをロードしたクラス・ローダーと同一であるとは限りません。
たとえば、DateFormatProvider
クラスの実装は、次のファイルを含むJARファイルの形態をとるべきです。
META-INF/services/java.text.spi.DateFormatProviderさらに、ファイル
java.text.spi.DateFormatProvider
には次のような行が含まれているべきです。
com.foo.DateFormatProviderImpl
これは、DateFormatProvider
を実装するクラスの完全指定クラス名です。
ロケール依存サービスの呼出し
java.text
およびjava.util
パッケージ内のロケールに依存するファクトリ・メソッドや名前取得メソッドは、サービス・プロバイダのメソッドを必要に応じて呼び出すことで、要求されたロケールをサポートします。 それらのメソッドはまず、Java実行環境自体が要求されたロケールをサポートするかどうかをチェックし、サポートが使用可能であればそのサポートを使用します。 そうでない場合、それらは、適切なインタフェースのインストール済みプロバイダのisSupportedLocale
メソッドを呼び出すことで、要求されたロケールをサポートするプロバイダを検索します。 そのようなプロバイダが見つかった場合、そのプロバイダのその他のメソッドが呼び出され、要求されたオブジェクトまたは名前が取得されます。 ロケールがサポートされているかどうかを確認する場合、「ロケールの拡張機能」はデフォルトで無視されます。 (ロケールの拡張もチェックする場合は、isSupportedLocale
メソッドをオーバーライドする必要があります。) Java実行時環境自体もインストールされているプロバイダも要求されたロケールをサポートしない場合、メソッドは候補ロケールのリストを進み、マッチが見つかるまで、それぞれ使用可能かどうかのチェックを繰り返します。 候補ロケールのリストの作成に使用されるアルゴリズムは、デフォルトでResourceBundle
によって使用されるものと同じです(詳細についてはgetCandidateLocales
を参照してください)。 候補リストからロケールが解決された場合でも、要求されたオブジェクトまたは名前を返すメソッドは、Locale
拡張を含む元の要求されたロケールで呼び出されます。 Java実行時環境は、この処理が確実に終了するように、すべてのロケールに依存するサービスのルート・ロケールをサポートする必要があります。
名前のプロバイダ(その他のオブジェクトのプロバイダではない)は、getAvailableLocales
の戻り値に含めることでサポートを宣言したロケールに対しても、一部の名前要求にnullを返すことが許されています。 同様に、Java実行環境自体は、サポートするすべてのロケールのすべての名前を保持していなくてもかまいません。 これは、名前の要求対象となるオブジェクト群が、規模が大きかったり時間の経過に従って変化したりする可能性があるため、それらを完全にカバーすることが常に実現可能とはかぎらないからです。 Java実行環境またはプロバイダが名前の代わりにnullを返した場合、そのロケールがまるでサポートされていなかったかのように、上記で説明したとおりに検索処理が進みます。
ロケール依存サービスの検索順序は、java.locale.providers
システム・プロパティを使用して構成できます。 このシステム・プロパティは、ユーザーの優先される、ロケールに依存するサービスの検索順序をカンマで区切って宣言します。 このプロパティ値は、このクラスの初期化時にのみ読取りおよびキャッシュされるため、ユーザーはjavaランチャのコマンドラインでプロパティを指定する必要があります。 実行時にSystem.setProperty(String, String)
で設定することはお薦めせず、順序に影響しない場合があります。 JDKリファレンス実装には、次の3つのロケール・データ・プロバイダが用意されています:
- "CLDR": Unicodeコンソーシアムの「共通ロケール・データ・リポジトリ(CLDR)」に基づくロケール・データ・プロバイダ。
- "SPI": この
LocaleServiceProvider
クラスのサブクラスを実装するロケール依存サービスを表します。 - "HOST": 基礎となるオペレーティング・システムでのユーザーのカスタム設定を反映するロケール・データ・プロバイダ。 このプロバイダは、JDKリファレンス実装によっては使用できない場合があります。
たとえば、プロパティに次が指定されている場合:
java.locale.providers=SPI,CLDRSPIプロバイダ内のロケールに依存するサービスが最初に検索されます。 必要なロケールに依存するサービスが使用できない場合、ランタイムはCLDRを検索します。
優先ロケール・データ・プロバイダを検索するデフォルト値は"CLDR"であるため、"CLDR"のみを指定することはデフォルトの動作と同じです。 ロケール依存サービスの実装を必要とするアプリケーションは、Javaランタイムがクラスパスからロードできるように、"SPI"を明示的に指定する必要があります。
- 実装上のノート:
- JDKでは、Unicodeコンソーシアムの「共通ロケール・データ・リポジトリ(CLDR)」のロケール・データを使用して、
java.util
およびjava.text
パッケージにロケール依存のAPIを実装します。 このロケール・データは、Javaランタイム環境でサポートされている一連のロケールを導出します。 次の表に、各JDKリリースで使用されるCLDRのバージョンを示します。 特に指定がないかぎり、特定のJDKリリース・ファミリのすべての更新リリースで同じCLDRバージョンが使用されます。 CLDRロケール・データは変更される可能性があります。 ユーザーは、ロケール・データがCLDRバージョン間で同じままであることを想定しないでください。 そうしないと、日付の解析時に例外など、予期しない互換性のない動作が発生する可能性があります。 リリース間のデルタについては、「CLDRリリース」を参照してください。JDKリリース CLDRバージョン JDK 23 CLDR 45 JDK 22 CLDR 44 JDK 21 CLDR 43 JDK 20 CLDR 42 JDK 19 CLDR 41 JDK 18 CLDR 39 JDK 17 CLDR 39 JDK 16 CLDR 38 JDK 15 CLDR 37 JDK 14 CLDR 36 JDK 13 CLDR 35.1 JDK 12 CLDR 33 JDK 11 CLDR 33 JDK 10 CLDR 29 JDK 9 CLDR 29 JDK 8 CLDR 21.0.1 - 導入されたバージョン:
- 1.6
-
コンストラクタのサマリー
コンストラクタ -
メソッドのサマリー
修飾子と型メソッド説明abstract Locale[]
このロケール・サービス・プロバイダがローカライズ済みのオブジェクトや名前を提供可能な、すべてのロケールを含む配列を返します。boolean
isSupportedLocale
(Locale locale) 指定されたlocale
がこのロケール・サービス・プロバイダでサポートされている場合はtrue
を返します。
-
コンストラクタの詳細
-
LocaleServiceProvider
protected LocaleServiceProvider()新しいロケール・サービス・プロバイダを初期化します。- 例外:
SecurityException
- セキュリティ・マネージャがインストールされていて、RuntimePermission("localeServiceProvider")
を拒否した場合
-
-
メソッドの詳細
-
getAvailableLocales
public abstract Locale[] getAvailableLocales()このロケール・サービス・プロバイダがローカライズ済みのオブジェクトや名前を提供可能な、すべてのロケールを含む配列を返します。 この情報は、DateFormat.getAvailableLocales()
など、ロケールに依存するサービスのgetAvailableLocales()
値を構成するために使用されます。このメソッドによって返される配列には、拡張だけが異なる複数の
Locale
オブジェクトを含めないでください。- 戻り値:
- このロケール・サービス・プロバイダがローカライズされたオブジェクトまたは名前を提供できるすべてのロケールの配列
-
isSupportedLocale
public boolean isSupportedLocale(Locale locale) 指定されたlocale
がこのロケール・サービス・プロバイダでサポートされている場合はtrue
を返します。 指定されたlocale
には、サポートの判断で考慮すべき拡張が含まれることがあります。指定された
locale
と使用可能なロケールの両方のすべての拡張を無視して、指定されたlocale
が、getAvailableLocales()
によって返される使用可能ないずれかのLocale
に等しい場合、デフォルトの実装はtrue
を返します。 具象ロケール・サービス・プロバイダ実装がLocale
拡張対応である場合、それらの実装ではこのメソッドをオーバーライドしてください。 たとえば、DecimalFormatSymbolsProvider
実装では、指定されたlocale
の拡張をチェックし、番号付けシステムが指定されていて、サポートできるかどうかを確認する必要があります。 ただし、CollatorProvider
実装は、特定の番号付けシステムに影響を受けないことがあり、その場合は、番号付けシステムの拡張を無視してください。- パラメータ:
locale
- テストするLocale
- 戻り値:
- 指定された
locale
がこのプロバイダでサポートされる場合はtrue
を返し、それ以外の場合はfalse
を返します。 - 例外:
NullPointerException
- 指定されたlocale
がnull
の場合- 導入されたバージョン:
- 1.8
- 関連項目:
-