クラスLocaleServiceProvider
- 直系の既知のサブクラス:
BreakIteratorProvider,CalendarDataProvider,CalendarNameProvider,CollatorProvider,CurrencyNameProvider,DateFormatProvider,DateFormatSymbolsProvider,DecimalFormatSymbolsProvider,LocaleNameProvider,NumberFormatProvider,TimeZoneNameProvider
これは、ロケールに依存するすべてのサービス・プロバイダ・インタフェース(SPI)のスーパー・クラスです。
ロケールに依存するサービス・プロバイダ・インタフェースは、各サービスに使用されるロケール・データを提供するために、java.textおよびjava.utilパッケージのロケール依存クラスに対応するインタフェースです。 これらのインタフェースを使えば、これらのパッケージでロケール依存オブジェクトを構築したりローカライズされた名前を取得したりできます。 java.textおよびjava.utilパッケージ内のロケールに依存するファクトリ・メソッドや名前取得メソッドは、プロバイダ・インタフェースの実装を使用することで、Java実行環境自体がサポートする一連のロケールに含まれないロケールをサポートします。 ロケール・センシティブ・サービス・プロバイダは、アプリケーション・モジュール・パスまたはアプリケーション・クラス・パスにデプロイされます。 検索するには、プロバイダをsystem class loaderに表示する必要があります。 ロケールに依存するサービス・プロバイダをモジュールまたはクラス・パスとしてデプロイする方法の詳細は、Deploying Service Providersを参照してく さい。
ロケール依存サービス・プロバイダ実装のパッケージ化
モジュールにデプロイされたロケール依存のサービス・プロバイダの 合、モジュール宣言にprovidesディレクティブを指定する必要があります。 providesディレクティブは、サービスとサービス・プロバイダの両方を指定します。
たとえば、モジュールとしてデプロイされたDateFormatProviderクラスの実装では、次のディレクティブを指定できます:
provides java.text.spi.DateFormatProvider with com.example.ExternalDateFormatProvider;
クラス・パスにデプロイされたロケール・サービス・プロバイダの 合、プロバイダは、リソース・ディレクトリ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 24 CLDR 46 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[]このロケール・サービス・プロバイダがローカライズ済みのオブジェクトや名前を提供可能な、すべてのロケールを含む配列を返します。booleanisSupportedLocale(Locale locale) 指定されたlocaleがこのロケール・サービス・プロバイダでサポートされている 合はtrueを返します。
-
コンストラクタの詳細
-
LocaleServiceProvider
protected 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
- 関連 目:
-