The original java.lang.Date was extremely parochial. It had a constructor that could build a date object from mm, dd, and yy values, for example - which assumed Western calendar values and the UTC timezone. That particular constructor has been deprecated for a very, very, long time. But it has not been removed because people find it convenient even though it's treacherous.
Java as a rule, however, is very international. So the Calendar classes were designed for the benefit of dates that aren't Western Gregorian format and dates in effect in other timezones than just UTC. Also, the Calendar classes support "date arithmetic" functions to make it easier to deal with the various warts in things like the Gregorian calendar: months of differing numbers of days, months whose length varies (February in Leap Year) and stuff like that.
Calendar was a big improvement, but it was ultimately oriented towards Calendars and calendar functions. So more recently an improved set of date classes has also been added to the mix. They are sufficiently different from the original java.lang.Date that they were done independently rather than as an attempt to patch up java.lang.Date.
There's also java.sql.Date, which is the JDBC equivalent of java.lang.Date, but with the additional nightmare that different brands of databases deal with dates and times in different ways.
An IDE is no substitute for an Intelligent Developer.
If you ever use the newer date and time API, you will find it so much better than Date/Calendar that you will never want to use Date again. Oracle have recently been going through the public API and deprecating lots of classes and methods. They have deprecated several constructors and methods in java.util.Date, but not the whole class. Many of those deprecations, e.g. four of the six constructors, are old, going back to JDK1.1 in 1997/1998.