次のような質問があることは承知していますjava.util.日付とJoda-Time。しかし、少し調べてみたところ、両者の違いについてのスレッドは見つかりませんでした。java.time API（新着Java 8、 によって定義されますJSR310） そしてジョダタイム。
Java 8 の java.time API は Joda-Time よりもずっとクリーンで、多くのことができると聞きました。しかし、この 2 つを比較した例を見つけることができません。
- java.time ではできて、Joda-Time ではできないことは何ですか?
- java.time が Joda-Time よりも優れている点は何ですか?
- java.time を使用するとパフォーマンスが向上しますか?
ベストアンサー1
共通の特徴
a) どちらのライブラリも不変型を使用します。Joda-Time は、 のような追加の可変型も提供しますMutableDateTime。
b) さらに: どちらの図書館もデザイン研究からインスピレーションを受けていますエリック・エヴァンスの「TimeAndMoney」またはアイデアドメイン駆動スタイルについて語るマーティン・ファウラーだから彼らは多かれ少なかれ流暢なプログラミングスタイル（常に完璧というわけではありませんが ;-)）。
c) 両方のライブラリを使用すると、実際のカレンダー日付型 ( と呼ばれるLocalDate)、実際のウォールタイム型 ( と呼ばれるLocalTime)、および合成 ( と呼ばれる) が得られます。これは、古いおよびLocalDateTimeと比較すると非常に大きな利点です。java.util.Calendarjava.util.Date
getDayOfYear()d) どちらのライブラリもメソッド中心のアプローチを採用しており、の代わりにを使用するようにユーザーに推奨していますget(DAY_OF_YEAR)。 これにより、 と比較して多くの追加メソッドが発生しますjava.util.Calendar(ただし、後者は int を過度に使用するため、まったく型安全ではありません)。
パフォーマンス
@OO7による他の回答を参照してください。ミハイル・ヴォロンツォフの分析を指摘していますが、ポイント3（例外キャッチ）はおそらく時代遅れです。このJDKのバグ異なるパフォーマンス（一般的にはJSR-310）は、主に内部実装がジョダタイム常にマシン時間のような long プリミティブ (ミリ秒単位) を使用します。
ヌル
Joda-Time は、システム タイムゾーン、デフォルト ロケール、現在のタイムスタンプなどのデフォルトとして NULL を使用することが多いですが、JSR-310 は NULL 値をほぼ常に拒否します。
精度
JSR-310ハンドルナノ秒精度はJoda-Timeに制限されていますミリ秒精度。
サポートされているフィールド:
Java-8 (JSR-310) でサポートされているフィールドの概要は、temporal-package のいくつかのクラスで提供されています (例:クロノフィールドそしてウィークフィールド) 一方、Joda-Timeはこの分野ではかなり弱いです - 参照日付時刻フィールドタイプJoda-Time の最大の欠如は、ローカライズされた週関連のフィールドがないことです。両方のフィールド実装設計の共通点は、どちらも long 型の値に基づいていることです (他の型はなく、列挙型もありません)。
列挙型
JSR-310は列挙型Joda-Timeは2002年から2004年にかけて主に開発されたため、この機能は提供されていませDayOfWeekん。MonthJava 5。
ゾーンAPI
a) JSR-310 は Joda-Time よりも多くのタイムゾーン機能を提供します。後者はタイムゾーン オフセット遷移の履歴にプログラムでアクセスできませんが、JSR-310 はこれが可能です。
b) 参考までに: JSR-310 は内部タイムゾーン リポジトリを新しい場所と異なる形式に移動しました。古いライブラリ フォルダー lib/zi はもう存在しません。
調整者対財産
JSR-310 では、時間的な計算と操作を外部化するための形式化された方法として - インターフェースが導入されましたTemporalAdjuster。特にライブラリやフレームワークの作成者にとって、これは JSR-310 の新しい拡張機能を埋め込むための便利で比較的簡単な方法です (以前の の静的ヘルパー クラスに相当するものjava.util.Date)。
ただし、ほとんどのユーザーにとって、この機能の価値は非常に限られています。コードを書く負担は依然としてユーザーにあるからです。新しいコンセプトに基づく組み込みソリューションはそれほど多くなく、現在は限られた操作セット (および列挙型またはその他の一時型)を備えたTemporalAdjusterヘルパー クラスしかありません。TemporalAdjustersMonth
Joda-Timeはフィールドパッケージを提供していますが、実践では新しいフィールドの実装はコーディングが非常に難しいことが証明されています。一方、Joda-Timeは、JSR-310よりもはるかに簡単でエレガントな操作を可能にするいわゆるプロパティを提供しています。たとえば、プロパティ.withMaximumValue()。
暦体系
JSR-310には4つの追加カレンダーシステムがあります。最も興味深いのはウマルクラ(サウジアラビアで使用)。他の 3 つは次のとおりです。ミンゴ（台湾）、日本（1871年以降は現代暦のみ！）、タイ仏教徒(1940 年以降のみ正しい)。
Joda-Timeはイスラム暦計算ベースです。Umalqura のような目視ベースのカレンダーではありません。Thai-Buddhist も Joda-Time によって同様の形式で提供されていますが、Minguo と日本のカレンダーは提供されていません。それ以外に、Joda-Time はコプト暦とエチオピア暦も提供しています (ただし、国際化はサポートされていません)。
ヨーロッパ人にとってさらに興味深いのは、Joda-Timeがグレゴリオ暦、ジュリアンおよび混合グレゴリオ暦とユリウス暦。ただし、日付履歴における異なる年の開始などの重要な機能がまったくサポートされていないため、実際の履歴計算に対する実用的な価値は限られています (同じ批判は old にも当てはまります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);
ジョダタイム =>int days = DAYS.daysBetween(date1, date2).getDays();
複数単位期間の扱いも異なります。計算結果も異なる場合があります。こちらを参照してください。Joda-Time の問題JSR-310 では、クラスPeriod(年、月、日に基づく期間) とDuration(秒とナノ秒に基づく期間) のみを使用する非常に単純で限定的なアプローチが採用されていますが、Joda-TimePeriodTypeでは、期間 (Joda-Time では「期間」と呼びます) をどの単位で表現するかを制御するために、クラスを使用するより洗練された方法が採用されています。 -API はPeriodType使いにくいですが、JSR-310 では同様の方法はまったく提供されていません。特に、JSR-310 では、混合日付と時刻期間 (たとえば、日と時間に基づく) を定義することはまだできません。したがって、あるライブラリから別のライブラリに移行する場合は注意してください。議論されているライブラリは、部分的に同じクラス名であるにもかかわらず、互換性がありません。
間隔
JSR-310はこの機能をサポートしていませんが、Joda-Timeは限定的にサポートしています。こちらもご覧ください。SO-回答。
フォーマットと解析
両方のライブラリを比較する最良の方法は、同じ名前のクラスを表示することです。日付時刻フォーマッタビルダー（JSR-310）および日付時刻フォーマッタビルダーTemporalField(Joda-Time)。JSR-310バリアントは、フィールド実装者が次のような拡張ポイントをコーディングしていれば、あらゆる種類の処理も可能で、より強力です。解決する（））。しかし、私の意見では、最も重要な違いは次のとおりです。
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) の比較も含まれています。この投稿よりも詳細です。