Why was "new Date(int year, int month, int day)" deprecated?

Originally, Date was intended to contain all logic concerning dates, but the API designers eventually realized that the API they had so far was woefully inadequate and could not be cleanly extended to deal correctly with issues such as timezones, locales, different calendars, daylight savings times, etc.

So they created Calendar to deal with all that complexity, and relegated Date to a simple timestamp, deprecating all its functionality that dealt with formatting, parsing and individual date fields.

BTW, internally these methods such as Date(int, int, int) constructor now call Calendar, so if you see a difference in speed, then you're doing something wrong when calling Calendar.

The bottomline: It's not Java's Calendar API that is overly complex, it's the human concept of dates, and the only problem with Calendar is that it offers not much in the way of shortcuts to the most common usages.

The Java Date APIs have long been critized, see for instance this thread.

You might want to check out Joda-Time or Apache Commons Lang for alternative Date/Time utilities.

The answer is portability.

The class Date is not very flexible. You can define dates, but not with any transformation into other calendar formats. So Sun decided to use an additional class hierarchy (Calendar) to make it more flexible.

Nonetheless, it's not very handy.

Mostly because the original java.util.Date was bloated and not completely timezone aware and not internationalization friendly.

However, Date is still in use and very well, in Value Objects, or say as a data type. As far as you make it immutable explicitly, you can go with ease. I tend to think it must be immutable, for other purpose we have Calendar to manipulate. Where its lot of manipulation expected, one should consider something like, Joda-Time.

[Edited]

Just don't instantiate the Date, in the latter code. Its of no use. You may achieve a better result for your benchmark.