最近継承した私のアプリケーションは、コンストラクターに関する非推奨の警告でいっぱいです:
Date d = new Date(int year, int month, int day)
これほど単純なものが次のようなものに「置き換えられた」理由を誰かが知っているか、指摘できますか:
Date d = null;
Calendar cal = GregorianCalendar.getInstance();
cal.set(1900 + year, month, day);
d = cal.getTime();
明らかに、非推奨の警告自体は問題ではありませんが、このコンストラクターが削除された場合、何百万もの LOC が苦痛に泣き叫ぶことを想像できますか?
ベンチマークでの私の簡単なプレイでは、後者は実行に約 50% 多くの時間を要します。
当初は、Date日付に関するすべてのロジックを含めることを意図していましたが、API 設計者は最終的に、これまでの API がひどく不十分であり、タイムゾーン、ロケール、異なるカレンダー、夏時間などの問題を正しく処理するようにきれいに拡張できないことに気付きました。など
Calendarそのため、彼らはそのすべての複雑さに対処するために作成しDate、単純なタイムスタンプに追いやり、書式設定、解析、および個々の日付フィールドを処理するすべての機能を廃止しました.
Date(int, int, int)ところで、コンストラクターなどのこれらのメソッドは内部的に を呼び出すようCalendarになったため、速度に違いが見られる場合は、 を呼び出すときに何か間違ったことをしていますCalendar。
結論: 過度に複雑なのは Java のCalendarAPI ではなく、人間の日付の概念であり、唯一の問題Calendarは、最も一般的な使用方法への近道があまり提供されないことです。
Java Date API は長い間批判されてきました。たとえば、このスレッドを参照してください。
代替の日付/時刻ユーティリティについては、Joda-TimeまたはApache Commons Langを確認してください。
答えは移植性です。
クラスDateはあまり柔軟ではありません。日付を定義できますが、他のカレンダー形式に変換することはできません。そのため、Sun は追加のクラス階層 ( Calendar) を使用して柔軟性を高めることにしました。
とはいえ、あまり便利ではありません。
主な原因は、元の java.util.Date が肥大化しており、タイムゾーンを完全に認識しておらず、国際化に対応していないためです。
ただし、日付はまだ使用されており、値オブジェクトで、またはデータ型として使用されています。明示的に不変にする限り、簡単に行くことができます。Calendar を操作する他の目的のために、それは不変でなければならないと考える傾向があります。多くの操作が予想される場合は、Joda-Time のようなものを検討する必要があります。
【編集済】
後者のコードでは、日付をインスタンス化しないでください。役に立たない。ベンチマークでより良い結果が得られる場合があります。
もちろん、他のカレンダー形式を使用する人は誰もいませんが、新しい API により、99% の一般的なケースで記述するコードの量が増えるため、LoC で支払われる Java プログラマーにとっては大きな恩恵です。
技術的には、Michael Borgwardt が最良の答えを持っていました。しかし、なぜ彼は太陽系の配置を人間のせいにするのでしょうか?
OK、私たちは秒、分、時間というアイデアを思いつきました。
しかし、その地球の日がおおよそのものであることは私たちの責任ではありません (真の太陽日、平均太陽日、または恒星日について話しているかどうかに応じて、それぞれが定期的かつランダムに変化します)。地球が太陽の周りを公転する時間が約365日であることは私たちのせいではありません。熱帯、変則的、または竜の（ノーディカル）月）。
カレンダーがこれらすべての詳細を考慮していないことをうれしく思いませんか? その場合、ソフトウェアのバグは確かに月の満ち欠けに依存している可能性があります。