モジュール java.base
パッケージ java.util.spi

クラスLocaleServiceProvider

java.lang.Object
java.util.spi.LocaleServiceProvider
直系の既知のサブクラス:
BreakIteratorProvider, CalendarDataProvider, CalendarNameProvider, CollatorProvider, CurrencyNameProvider, DateFormatProvider, DateFormatSymbolsProvider, DecimalFormatSymbolsProvider, LocaleNameProvider, NumberFormatProvider, TimeZoneNameProvider
public abstract class LocaleServiceProvider extends Object

これは、ロケールに依存するすべてのサービス・プロバイダ・インタフェース(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リファレンス実装では、次の4つのロケール・プロバイダが提供されます:

  • "CLDR": Unicode Consortiumの「CLDRプロジェクト」に基づくプロバイダ。
  • "COMPAT": JDK 8 (JDK 8の"JRE"と同じ)までの以前のJDKリリースと互換性のあるロケール依存サービスを表します。 このプロバイダは非推奨であり、JDKの将来のリリースで削除されます。
  • "SPI": このLocaleServiceProviderクラスのサブクラスを実装するロケール依存サービスを表します。
  • "HOST": 基礎となるオペレーティング・システムでのユーザーのカスタム設定を反映するプロバイダ。 このプロバイダは、JDKリファレンス実装によっては使用できない場合があります。
  • "JRE": "COMPAT"と同義語を表します。 この名前は非推奨であり、JDKの将来のリリースで削除されます。

たとえば、プロパティに次が指定されている場合: 

 java.locale.providers=SPI,CLDR,COMPAT
SPIプロバイダ内のロケールに依存するサービスが最初に検索されます。 目的のロケール依存サービスが使用できない場合、ランタイムはその順序でCLDR、COMPATを検索します。

優先ロケール・プロバイダを検索するデフォルトの順序は"CLDR,COMPAT"であるため、"CLDR,COMPAT"の指定はデフォルトの動作と同じです。 ロケール依存サービスの実装を必要とするアプリケーションは、Javaランタイムがクラスパスからロードできるように、"SPI"を明示的に指定する必要があります。

導入されたバージョン:
1.6