Quality Outreach Heads-up – JDK 20-23: Support for Unicode CLDR Version 42

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

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

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

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

JDK 20 – Support for Unicode CLDR Version 42

【訳注】原文では、以下のエントリを更新していますが、ここではそのまま翻訳して記載しています。

Quality Outreach Heads-up – JDK 20: Support for Unicode CLDR Version 42
https://logico-jp.io/2023/03/29/quality-outreach-heads-up-jdk-20-support-for-unicode-cldr-version-42/

JDKのロケールデータはUnicode ConsortiumのUnicode Common Locale Data Repository (CLDR) に基づいています。2022年12月のQuality Outreachニュースレターに記載した通り、JDK 20ではCLDRを2022年10月リリースのversion 42にアップグレードしました。このバージョンには、通常の空白をno-break space(NBSP / \u00A0) やnarrow no-break space(NNBSP / \u202F) に置き換える、「より洗練された空白の扱い(more sophisticated DAIP handling of spaces)」が含まれています。

JDK 20 Rampdown Phase 1 & Valhalla LW4 Early-Access builds
https://mail.openjdk.org/pipermail/quality-discuss/2022-December/001100.html
CLDR 42 Release Note
https://cldr.unicode.org/index/downloads/cldr-42
Propose more sophisticated DAIP handling of spaces
https://unicode-org.atlassian.net/browse/CLDR-14032

  • 時間表記: a と時間の間
  • 単位表記: {0}と単位の間
  • キリル文字の日付表記: で、гのような年号の前

その他の重要な変更点は以下のようなものがあります。

標準のdate/timeフォーマットでは” at “を使わない[CLDR-14831] Add more dateTimePatters: relative+absolute time, date+timeInterval
https://unicode-org.atlassian.net/browse/CLDR-14831
(中国語)週の最初の曜日を修正[CLDR-11510] Fix first day of week info for China (CN)
https://unicode-org.atlassian.net/browse/CLDR-11510
(日本語)9999京までの数値をサポート[CLDR-15966] Japanese: Support numbers up to 9999京
https://unicode-org.atlassian.net/browse/CLDR-15966

結果として、日付や時刻のようなロケールに依存する文字列を生成、または解析するプロダクションコードやテストコードにて、破壊的な方法で動作が変わる可能性があります(たとえば、正規のスペースを含む手作業で生成した日付文字列を解析したにもかかわらず、パーサーがNBSPまたはNNBSPを期待するようになった場合など)。期待される文字列と実際の文字列は、さまざまなテキスト表現で非常に似ていたり、同じに見えたりするため、問題を分析するのは難しい場合があります。これらの問題を検出し修正するには、異なる種類の空白を異なる方法で表示するテキストエディタを使用するようにしてください。

JDK 20へのアップグレード時に必要な修正を実装できない場合、次のJVMオプションを使って旧来のロケールデータを使うことを検討してください。

-Djava.locale.providers=COMPAT

この方法ではロケール関連の機能が一部制限されるため、適切な解決策としてではなく、一時的な回避策として取り扱うことを念頭においてください。さらに、COMPATオプションは将来的に削除される予定です。

また、この種のロケールデータは定期的に進化するため、ロケールデータを解析/合成するプログラムは、JDKのリリースごとに定期的にチェックする必要がある点に留意することが重要です。

詳しくは、JDK-8284840をご覧ください。

[JDK-8284840] Update CLDR to Version 42.0
https://bugs.openjdk.org/browse/JDK-8284840

JDK 23 Update – Loose Matching of Space Separators

JDK 23以降では、date/time文字列の解析で空白の緩やかなマッチング (loose matching) が可能になります。この機能拡張は、主に上記の問題に対処するためのものです。java.time.formatパッケージとjava.textパッケージのdate/timeパーサーでは、寛大な解析スタイル (lenient parsing style) で緩やかなマッチングが行われます。デフォルトの厳密な解析スタイルでは、これらのスペースは以前と同様に区別されます。

java.time.formatパッケージで緩やかなマッチングを使用するには、アプリケーションで明示的にDateTimeFormatterBuilder.parseLenient()を呼び出して緩やかさを設定する必要があります。

var dtf = new DateTimeFormatterBuilder()
	.parseLenient()
	.append(DateTimeFormatter.ofLocalizedTime(FormatStyle.SHORT))
	.toFormatter(Locale.ENGLISH);

In the java.textパッケージの場合、デフォルトの解析モードが寛大 (lenient) なので、アプリケーションですべての空白を自動的に解析できます(つまりデフォルトの挙動がこの機能によって変わる)。厳密にテキストを解析する必要がある場合は以下のようにしてください。

var df = DateFormat.getTimeInstance(DateFormat.SHORT, Locale.ENGLISH);
df.setLenient(false);

詳細は、以下のBugをチェックしてください。

[JDK-8324665] Loose matching of space separators in the lenient date/time parsing mode
https://bugs.openjdk.org/browse/JDK-8324665

コメントを残す

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