我的應用我最近繼承全是有關構造廢棄警告的：爲什麼不推薦使用「新日期（int year，int month，int day）」？
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唯一的問題是，它提供了快捷的方式沒有太大的最常見的用法。
答案是可移植性。
該類Date不是很靈活。您可以定義日期，但不能轉換爲其他日曆格式。所以Sun決定使用額外的類層次結構（Calendar）以使其更加靈活。
儘管如此，它並不是非常方便。
Java Date API早已受到批評，例如參見this thread。
您可能想查看Joda-Time或Apache Commons Lang瞭解其他日期/時間實用程序。
主要是因爲原始的java.util.Date變得臃腫，並且沒有完全識別時區並且沒有國際化友好性。
但是，Date仍然在使用中，並且非常好，在Value Objects中，或者說作爲數據類型。只要你明確地使其不變，你就可以輕鬆地去。我傾向於認爲它必須是不可變的，因爲我們有Calendar來操作其他目的。在很多操縱預期的地方，人們應該考慮像Joda-Time。
[編輯]
只是不實例化的日期，在後者的代碼。它沒用。您可能會爲您的基準測試獲得更好的結果。
當然，沒有人曾經使用任何其他日曆格式，但新的API增加了代碼編寫的99％，常見的情況金額，所以它是由控制線支付Java程序員的一大福音。
Michael Borgwardt在技術上有最好的答案。但爲什麼他爲我們的太陽系佈局方式而責怪人類呢？
OK，我們想出了幾秒鐘的理念，分鐘和小時。
但是這不是我們的錯，是地球的一天是近似（取決於我們是否在談論真正的太陽日，平均太陽日，恆星或一天，每一個週期和隨機變化）。這不是我們的錯，地球軌道繞太陽的時間大約 365天，這不是我們的錯，繞地球月球的軌道是大約27.3天（取決於我們是否在談論一個恆星，朔望，熱帶，不規則，或龍脈（節日）月）。
你不是很高興，日曆沒有采取所有這些細節考慮在內？那麼我們的軟件錯誤可能確實取決於月球的相位。
是不是第一行總是浪費時間？你從cal得到一個Date到Calendar.getTime（），那麼爲什麼要用新的Date（）調用創建一個然後拋棄呢？特別是如果你是基準這... – unwind 2009-01-20 08:35:01
@ unwind：一個很好的捕獲。爲什麼不呢，發個帖子。 – 2009-01-20 09:01:59
也許是因爲美國人平均預期日期（年整型，詮釋天，月整型）;-) – Skizz 2009-01-20 09:55:50