web-dev-qa-db-ja.com

Java.util.Dateを使用するか、Java.time.LocalDateに切り替える必要があります

編集：まあ、明らかにそれはあまりにも意見に基づいていたので、私はそれをより正確に言い換えてみましょう-

Java下位互換性を必要としないコードでLocalDate、LocalTimeなどを使用することの明確な警告または欠点はありますか？

「現在のEEライブラリXおよびYはLocalDateで正しく動作しない」または「この非常に有用なパターンはLocalTimeで壊れています」などのようなものを探しています。

（参照用の元の質問です）

Java 8では、新しい時間API、つまりJava.time.LocalDateなどが導入されますが、Java.util.Dateは非推奨としてマークされません。

私は新しいプロジェクトを書いていますが、後方互換性は必要ありません。 LocalDate、LocalDateTimeなどのみを使用する必要がありますか？古き良きJava.util.Dateとは対照的に、この新しいAPIを使用することに欠点はありますか？

特に、私は主にJDBCで作業する予定です。私が見たところから、JDBCはJava.util.Dateをうまく処理します。 LocalDateにも適していますか？

検索により、ある形式から別の形式に変換する方法を示す多くのサイトが得られましたが、新しいコードで古いAPIを使用するかどうかについての明確な答えはありませんでした。

ありがとう。

javadatejdbc
47
Itai

名前にもかかわらず、Java.util.Dateは日付と時刻の両方を格納するために使用できます（エポック以降のUTCミリ秒オフセットを格納します）

より優れた機能があるため、私は間違いなく新しいAPIを使用します。

  • より簡単なフォーマット/解析。 APIには独自のフォーマット/解析メソッドがあります
  • APIには、加算/減算操作（minusMinutes、plusDaysなど）が含まれます

上記のどれもJava.util.Dateでは利用できません

古い日付は、次のようにLocalDateTimeに変換することもできます。

Date oldDate = ...
LocalDateTime newDateTime = 
  LocalDateTime.from(Instant.ofEpochMilli(oldDate.getTime()));
36
gerrytan

Java 8以降：心配なし

いいえ。Java 8以降（組み込みの場合）の場合、Java.time、最新のJava日時APIを使用したくない理由はありません。

簡単に考慮できるのは、すでに除外したものだけです。

私は新しいプロジェクトを書いていますが、後方互換性は必要ありません。

また、下位互換性のためにも、変換メソッドはJava 8の古いクラスに組み込まれているため、Java.timeを安全に使用できます。

Java 6および7：重量を量る

Java 6または7を使用している場合、 ThreeTen-Backport を使用する必要があります.time、 ThreeTenABP のAPIレベル26未満のAndroidにさらに適合します。非常に簡単な日付と時刻の作業をほとんど行わず、何らかの理由で前方互換性が問題にならない場合は、外部依存関係に価値があるかどうかを検討できます。外部依存関係はJava 8以降に組み込まれているもののバックポートであるため、堅実であるため、さらに必要になるのはJava 8に移行するか、後。その時点で、インポートを変更し、再テストしてバックポートを廃止できます。

考えられる負債の例

現在のEEライブラリXおよびYはLocalDateで正しく動作しません

その例がいくつかあり、JDKのライブラリクラスもあります。私の選択は、Java.timeを自分のコードで使用し、Java.time型をまだ受け入れていないAPIを呼び出す直前にのみ変換することです。逆に、APIから古いクラスのインスタンスを取得した場合は、最初にそれを変換し、残りの部分にはJava.timeを使用します。

この非常に便利なパターンはLocalTimeで壊れています

私はそのようなパターンを知りません。それどころか、Java.timeはパターン不変オブジェクトとfactory methodを使用し、ほとんどの古いクラスとは対照的です。

1
Ole V.V.