Quality Outreach Heads-up – Unicode in JDK 23: Removal of COMPAT Locale Provider

原文はこちら。
The original article was written by Nicolai Parlog (Java Developer Advocate at Oracle).
https://inside.java/2024/07/11/quality-heads-up/

OpenJDK Quality Groupは、リリースの全体的な品質向上の手段としてOpenJDKビルドを使ってのFOSSプロジェクトのテストを推進しています。

Quality Outreach
https://wiki.openjdk.java.net/display/quality/Quality+Outreach

このHeads upは、関係するプロジェクトに送られる定期的なコミュニケーションの一部です。このプログラムの詳細と参加方法については、上記wikiをご覧ください。

A Quick History of Locale Data in the JDK

Unicode Consortium（Unicodeコンソーシアム）がCommon Locale Data Repository（CLDR、共通ロケールデータリポジトリ） を2003年に作成してロケールデータを管理するまでは、JDK自身がロケール・コレクションを提供する必要がありました。JDKはうまく運用して、JDK 8で約160のロケールをサポートしました。メンテナンスの労力軽減、プラットフォーム間の相互運用性向上、ロケールデータの品質向上のため、JDKは2014 年からCLDRへの移行を開始しました。

JDK 8JRE/COMPAT：JDKのレガシーデータコレクション（デフォルト）
CLDR：CLDRのデータ
システムプロパティjava.locale.providersで選択できる
カスタムロケールプロバイダの実装が可能
JDK 9デフォルトロケールデータプロバイダをCLDRに変更
JDK 21JRE/COMPATに対して警告表示

レガシーデータと CLDR には、大小数多くの差異があります。最近書き直された JEP 252 に、そのうちのいくつかが記載されています。

JEP 252: Use CLDR Locale Data by Default
https://openjdk.org/jeps/252

Locale Data in JDK 23

JDK 23では、レガシーロケールデータが削除されました。そのため、java.locale.providersをJREやCOMPATに設定しても、何の効果もありません。

[JDK-8325568] Remove legacy locale data (COMPAT, JRE) from the JDK
https://bugs.openjdk.org/browse/JDK-8325568

レガシーロケールデータを現在も利用しているプロジェクトは、できる限り早くCLDRに切り替えることを強く推奨いたします。切り替えが難しい、不可能な場合には、以下の2個の代替策があります。

  • レガシーの動作を模倣するパターンを持つカスタムフォーマッターを作成し、ロケールに依存するデータが書き込まれたり解析されたりする箇所すべてでそれを使用する。
  • カスタムロケールデータプロバイダーを実装する。

Class LocaleServiceProvider (Java SE 22 & JDK 22)
https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/spi/LocaleServiceProvider.html

本件の詳細、ならびに一般的なJDKのCLDRに関する詳細情報は、JEP 252をチェックしてください。最近より詳細情報やガイダンスを提供できるように書き直されました。

JEP 252: Use CLDR Locale Data by Default
https://openjdk.org/jeps/252

コメントを残す

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください。