「新しい日付（int年、int月、int日）」が非推奨になったのはなぜですか？
私が最近継承した私のアプリケーションは、コンストラクタに関する非推奨の警告がいっぱいです：
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のCalendar APIではなく、人間の日付の概念であり、Calendarの唯一の問題は、ほとんどのショートカットをあまり提供しないことです。一般的な使用法。
Java Date APIは長い間批判されてきました。たとえば、 this thread を参照してください。
代替の日付/時刻ユーティリティについては、 Joda-Time または Apache Commons Lang をチェックアウトすることをお勧めします。
答えは移植性です。
クラスDateはあまり柔軟性がありません。日付は定義できますが、他のカレンダー形式への変換はできません。そこで、Sunは追加のクラス階層（Calendar）を使用して、より柔軟にすることにしました。
それにもかかわらず、それは非常に便利ではありません。
主に、元のJava.util.Dateが肥大化し、完全にタイムゾーンを認識せず、国際化に対応していなかったためです。
ただし、Dateは現在も使用されており、Value Object、またはデータ型として非常によく使用されています。明示的に不変にする限り、簡単に実行できます。カレンダーを操作する他の目的のために、それは不変でなければならないと思う傾向があります。多くの操作が予想される場合、Joda-Timeのようなものを検討する必要があります。
[編集済み]
後者のコードでは、Dateをインスタンス化しないでください。役に立たない。ベンチマークの結果が改善される可能性があります。
もちろん、誰も他のカレンダー形式を使用することはありませんが、新しいAPIは、99％の一般的なケースのために記述するコードの量を増やすため、Java LoC。
技術的には、マイケルボルグワードが最良の答えを出しました。しかし、なぜ彼は私たちの太陽系がレイアウトされている方法のために人間を非難するのですか？
OK、秒、分、時間のアイデアを思いつきました。
しかし、地球の日がおおよその日であるのは私たちのせいではありません（それぞれが周期的にランダムに変化する真の太陽の日、平均太陽の日、星の日について話しているかどうかによって異なります）。地球の太陽の周りの軌道がおよそ 365日であることは私たちのせいではなく、地球の周りの月の軌道がおよそ 27.3日であることは私たちのせいではありません（私たちが恒星、シノディック、トロピカル、アノマリスティック、またはドラコニック（ノディカル）月について話しているかどうかに応じて）.
カレンダーがこれらすべての詳細を考慮しなかったことを嬉しく思いませんか？その場合、ソフトウェアのバグは実際に月の満ち欠けに依存している可能性があります。