I try to avoid Calendar as much as possible. It has an API from hell - far more complex than I need most of the time. I favor using the simplest classes that accomplish what I need - usually that's Date and SimpleDateFormat. My code will be easier for others to understand if I don't use classes with a lot of unnecessary methods. And it's extremely counterintuitive to me that (for example) the MONTH field starts at 0 (Jan) while DAY_OF_MONTH and DAY_OF_WEEK start at 1. Plus, a GregorianCalendar instance has a lot more instance data than a Date does. For a single object it's no big deal - but if you have many thousands of rows of table data you want to store in memory, you want to store dates using Date rather than Calendar, or the memory difference will be notable.
Having said that, what
is Calendar good for? Well, anything that depends on an understanding of human calendar systems. (Except for parsing and formatting dates, which is best done by SimpleDateFormat.) Examples: is today a weekday? When does the first Tuesday of the next month occur? Is this a leap year? How can I take the current date and set the time part to 5:00 P.M.? These are all questions that are easiest to answer with a Calendar.
I think of the relationship between Calendar and Date as being similar to that between StringBuffer and
String. You use a StringBuffer to manipulate a string and change its value - but most of the time when you're done manipulating, you call toString() and just save the equivalent String value after that. Likewise, use a Calendar to change date information when you need to - but when you're done, use getTime() to extract the equivalent Date obejct, which will be simpler for everyone to understand.
Note that Date really
should have been immutable (like String), but it isn't. Sun engineers have acknowledged this was a mistake, but they can't really correct it now, since the API has been released to the public. They might one day deprecate setTime() I suppose; hasn't happened yet though.