Java 8 Date API vs Calendar / Date / DateFormat
Java 8、 Java.timeパッケージ にこのnew-n-cool Date APIがあります。であることを理解しています古いクラスよりも優れた設計で、あいまいさが少なく、スレッドセーフですが、それでも、どのように使用すればよいかわかりません。
- 古いクラスの代わりに排他的に使用する必要がありますか？
- 新しいものの方がはるかに優れているので、古いクラスの既存の使用法を見つけた場所で置き換える必要がありますか？
Java.util.Calendar, Java.util.Date、Java.sql.Date、およびJava.text.DateFormatを使用せずに、新しいAPIをまとめて使用する必要がありますORユースケースはありますか古いクラスがまだ望ましいところ？- Guava FluentIterable をJava 8ストリームAPIに置き換えるのと同様に、新しいDate APIのおかげで Joda Time API は廃止されましたか？
これらは多くの質問であることを私は知っていますが、それらは互いにいくらか関連しているように感じます。誰かが全部に答えることができれば、それは素晴らしいことですが、良い部分的な答えもありがたいです。
古いクラスの代わりに排他的に使用する必要がありますか？
いいえ、古いクラスを除外する必要はありません。古いJava.util.Date/.Calendarは同じように機能しますが、変更はありません。 havenotは非推奨になりました。
3つのフレームワーク（古いクラス、Joda-Time、およびJava.time）すべてを組み合わせて組み合わせることができます。いくつかの同一または類似のクラス名に注意してください-importステートメントに注意してください！
チュートリアルを参照してください レガシー日時コード 。
また、 ThreeTen-Extra プロジェクトは、Java.timeを追加機能で拡張します。 「ThreeTen」は、Java.timeを定義する JSR 31 を指します。
新しいものの方がはるかに優れているので、古いクラスの既存の使用法を見つけた場所で置き換える必要がありますか？
古いコードが意図したとおりに機能している場合は、今すぐ変更する必要はありません。
古いコードがタイムゾーンを適切に処理していない可能性があることを懸念している場合、またはより多くのローカリゼーションを実行したい場合は、Java.timeを使用してそれらを作り直すことをお勧めします。それでも、j.u.DateとInstantの間で簡単に変換できることを忘れないでください。したがって、j.u.Date/.Calendarを使用してビジネスロジックをそのままにし、Java.timeを使用するようにユーザープレゼンテーションコードのみを変更することができます。
Java.util.Calendar、Java.util.Date、Java.sql.Date、Java.text.DateFormatを使用せずに、新しいAPIをまとめて使用する必要がありますOR使用例はありますか？古いクラスがまだ望ましいところはどこですか？
古いタイプを期待する古いコードやライブラリと相互運用するには、古いクラスが必要になります。繰り返しになりますが、古いクラスは非推奨ではなく、なくなることもありません。それらは、広範囲に使用され、Javaチームの最優先事項は下位互換性の維持であるため、おそらくなくなることはありません。
新しいJava.timeクラスははるかに優れているため、追加されました。そして、それらはより論理的で使いやすいです。そうです、それらの使い方を学ぶことは有益で楽しいでしょう。しかし、緊急ではありません。クランチでは、あなたが慣れている古い方法でコードを書いてください。学習する時間（ チュートリアル ）と追加のテストを実行する時間ができたら、新しいクラスの使用を開始します。
初心者プログラマーは確かにJava.timeに学習を集中する必要があります。
GuavaFluentIterableをJava 8ストリームAPIに置き換えたのと同様に、新しいDate APIのおかげで、Joda Time APIは廃止されましたか？
Joda-TimeはJava.timeのインスピレーションでした。同じ人々が両方を発明しました。彼らは、Java.timeがJoda-Timeの「2.0」の再発明になることを意図しています。彼らが今知っていることを知っていれば、彼らは何をしたでしょう。彼らは、Joda-TimeユーザーはJava.timeに移行すべきだと言っています。
とはいえ、Joda-Timeはなくなることはありません。それはまだ作業中であり、バグ修正と新しいtzタイムゾーンデータで更新されています。そして、それはvery重要です（私が知っている他のまともな日時ライブラリを持っていない大規模なAndroidコミュニティ）したがって、引き続きJoda-Timeに依存することができ、古いコードを緊急に削除する必要はありませんが、新しい機能や拡張機能は期待できません。
Joda-Timeは使い古されており、実績がありますが、Java.timeにはいくつかの小さなバグや問題があります。 Joda-TimeとJava.timeには、それぞれ他に欠けている機能があります。個人的には、自分に合うように組み合わせます。 Java.timeに手を出している間、私はJoda-Timeに依存しています。
Java.timeへの最終的な移行を計画しますが、ラッシュやパニックはありません。