[解決済み】Java 8 の Date Time API (java.time) と Joda-Time の相違点

質問

に関連する質問があることは承知しています。 java.util.Date とJoda-Timeがあります。しかし、いくつか調べてみたところ、Joda-TimeとJoda-Timeの違いに関するスレッドは見つかりませんでした。 java.time API (での新機能）。 ジャバ8 で定義されています。 JSR 310 ) と ジョダタイム .

Java 8のjava.time APIはJoda-Timeよりずっときれいで、ずっと多くのことができると聞いています。しかし、この2つを比較した例を見つけることができません。

• java.timeにできて、Joda-Timeにできないことは何ですか？
• java.timeはJoda-Timeより何が優れているのですか？
• java.timeを使用した場合、パフォーマンスは向上しますか？

解決方法は？

共通機能

a) 両ライブラリともimmutable型を使用します。Joda-Timeはさらに、以下のようなミュータブル型も提供しています。 MutableDateTime .

b) さらに 両ライブラリは、デザインスタディにインスパイアされています Eric Evans氏による「TimeAndMoney"」。 のアイデア、あるいは Martin Fowlerによるドメイン駆動型スタイルについて で、多かれ少なかれ 流暢なプログラミングスタイル (常に完璧というわけではありませんが;-))。

c) 両方のライブラリで、本物のカレンダーの日付タイプ ( LocalDate ) 、実際の壁の時間タイプ ( LocalTime ) とコンポジション ( LocalDateTime ). これは、古い java.util.Calendar と java.util.Date .

d) 両ライブラリとも、メソッド中心のアプローチを採用しているため、ユーザーに getDayOfYear() の代わりに get(DAY_OF_YEAR) . と比べて、余計なメソッドが多くなってしまいます。 java.util.Calendar (後者はintを多用するため、型安全性が全くありませんが）。

パフォーマンス

3 (例外の捕捉) はおそらく時代遅れですが、Mikhail Vorontsov の分析を指摘する @OO7 の他の回答を参照してください - 参照。 このJDK-bug . 性能の違い（一般的に有利なのは JSR-310 の内部実装に起因するものです。 ジョダタイム は常に機械時間的なロングプリミティブ（ミリ秒単位）を使用します。

Null

Joda-Timeはシステムタイムゾーン、デフォルトロケール、カレントタイムスタンプなどのデフォルトとしてNULLを使用しますが、JSR-310はほぼ常にNULL値を拒否します。

精度

JSR-310のハンドル ナノ秒 の精度に制限されているのに対し、Joda-Timeは ミリ秒 の精度です。

対応するフィールド

Java-8 (JSR-310) でサポートされているフィールドの概要は、temporal-package のいくつかのクラスで説明されています (たとえば クロノフィールド と ウィークフィールド を参照）一方、Joda-Timeはこの分野ではかなり弱いです。 日付時間フィールドタイプ . Joda-Timeの最大の欠点は、ローカライズされた週に関するフィールドが存在しないことです。両方のフィールド実装デザインの共通点は、どちらも long 型の値に基づいていることです（他の型、enum もありません）。

列挙

JSR-310の提供 列挙 のように DayOfWeek または Month Joda-Timeは主に2002年から2004年にかけて開発されたため、このような機能はありません。 Java 5 .

ゾーンAPI

a) JSR-310はJoda-Timeより多くのタイムゾーン機能を提供します。Joda-Timeはタイムゾーンオフセット遷移の履歴にプログラム的にアクセスすることができませんが、JSR-310はこれを行うことが可能です。

b) ご参考までに。JSR-310は内部のタイムゾーンリポジトリを新しい場所と異なるフォーマットに移動しました。古いライブラリフォルダlib/ziはもう存在しません。

アジャスターとプロパティの比較

JSR-310で導入された TemporalAdjuster -特にライブラリやフレームワークの作者にとっては、JSR-310 の新しい拡張を埋め込むのに便利で比較的簡単な方法です。 java.util.Date ).

しかし、多くのユーザーにとっては、コードを書く負担が残るため、この機能の価値は非常に限定的です。新しい TemporalAdjuster -のコンセプトはそれほど多くなく、現在のところヘルパークラスの TemporalAdjusters という限られた操作しかできない（そして列挙された Month または他の一時的な型)。

Joda-Timeはフィールド・パッケージを提供していますが、新しいフィールド実装のコーディングは非常に難しいという証拠があります。一方、Joda-Timeは、JSR-310よりはるかに簡単でエレガントな操作を可能にする、いわゆるプロパティを提供します。 プロパティ.withMaximumValue() .

カレンダーシステム

JSR-310は、4つのカレンダーシステムを提供しています。最も興味深いのは ウマルクラ (サウジアラビアで使用)。他の3つは みんゴル (台湾)、日本(1871年から近代暦のみ!)、そして タイ仏教 (1940年以降のみ正しい)。

Joda-Timeでは イスラム暦 ウマルクラのような視準ベースのカレンダーではなく、計算ベースのカレンダーです。タイ仏教もJoda-Timeで同様の形式で提供されていますが、Minguoと日本のものはそうではありません。その他、Joda-Timeはコプト暦とエチオピア暦も提供している（ただし、国際化のサポートはない）。

ヨーロッパの人々にはもっと興味深いことがあります。Joda-Timeはまた グレゴリアン , ジュリアン とグレゴリオ暦とユリウス暦の混合暦があります。しかし、日付の歴史における異なる年の始まりといった重要な機能が全くサポートされていないため、実際の歴史計算における実用的な価値は限られています (同じ批判は、昔の java.util.GregorianCalendar ).

などの他のカレンダーもあります。 ヘブライ語 または ペルシャ語 または ヒンズー教 が両ライブラリとも完全に欠落している。

エポックメイキング

JSR-310は、クラス ジュリアンフィールド 一方、Joda-Time (バージョン 2.0) は、いくつかのヘルパー・メソッドをクラス 日付時間ユーティリティ .

時計

JSR-310はインターフェイスを持たず（設計ミス）、抽象クラスで構成されている java.time.Clock これは、あらゆるクロック依存性注入に使用することができます。Joda-Timeはインターフェイスを提供します。 ミリスプロバイダー といくつかのヘルパーメソッドが 日付時間ユーティリティ の代わりに このように、Joda-Timeは異なるクロック（モッキングなど）を持つテスト駆動モデルをサポートすることも可能です。

持続時間の計算

どちらのライブラリも、1つまたは複数の時間単位での時間距離の計算をサポートしています。しかし、単一の時間単位を扱う場合は、JSR-310スタイルの方が明らかに優れています（intを使用する代わりにlongベース）。

JSR-310 => long days = ChronoUnit.DAYS.between(date1, date2);

Joda-Time => int days = DAYS.daysBetween(date1, date2).getDays();

また、複数台数の場合の処理も異なります。計算結果も異なることがあります。 Joda-Timeの問題 . JSR-310 では、非常にシンプルで限定的なアプローチで、単にクラス Period (年、月、日に基づく期間) と Duration (秒とナノ秒に基づく)、Joda-Time はより洗練された方法で PeriodType は、持続時間（Joda-Timeでは "Period"と呼ぶ）がどの単位で表現されるかを制御するために使用されます。一方 PeriodType -APIは使いにくいので、JSR-310では同じような方法は提供されていません。特に、日付と時間が混在した期間を定義することは、JSR-310ではまだ不可能です（例えば、日数と時間を基準にした期間）。ですから、あるライブラリから別のライブラリに移行する場合は、注意が必要です。議論されているライブラリは、クラス名が一部同じであるにもかかわらず、互換性がありません。

インターバル

JSR-310はこの機能をサポートしておらず、Joda-Timeは限定的にサポートしています。こちらもご覧ください SO-アンサー .

書式設定と構文解析

両ライブラリを比較するには、同じ名前のクラスを表示するのが一番です。 DateTimeFormatterBuilder (JSR-310)と DateTimeFormatterBuilder (Joda-Time)です。JSR-310-バリアントは、もう少し強力です（あらゆる種類の TemporalField のような拡張ポイントをフィールド実装者が何とかコード化している場合に限ります。 resolve() ). 最も重要な違いは、しかし - 私の意見では。

JSR-310はタイムゾーン名（フォーマットパターン記号z）をより良く解析することができますが、Joda-Timeはその初期バージョンでは全くできず、現在では非常に限られた方法のみとなっています。

JSR-310のもう一つの利点は、ロシア語やポーランド語などの言語において重要な、独立した月名のサポートです。Joda-Timeは そのようなリソースにアクセスできない - Java-8プラットフォーム上でさえない。

JSR-310のパターン構文は、Joda-Timeよりも柔軟で、（角括弧を使った）オプションのセクションを許容し、CLDR-標準をより指向し、パディング（文字記号p）とより多くのフィールドを提供します。

その他に、Joda-Timeでは、持続時間のフォーマットを ピリオドフォーマッタ . JSR-310ではできません。

この概要がお役に立てれば幸いです。集められたすべての情報は、主に私の努力と、より良い日付と時刻のライブラリを設計し実装する方法についての調査によって得られたものです（完璧なものなどありません）。

2015-06-24より更新しました。

その間、私は執筆の時間を確保し 表形式の概要を公開する Java の様々な時間ライブラリについて。表にはJoda-Time v2.8.1とJava-8 (JSR-310)の比較も含まれています。この投稿よりも詳細です。