java.util.Date与java.util.Calendar是否已废弃？Java 8后是否仍需使用或完全规避？

Great question—this is a super common point of confusion for developers moving from pre-Java 8 codebases to modern Java practices. Let’s break this down clearly:

Are java.util.Date and java.util.Calendar deprecated? #

Short answer: The classes themselves are not marked as deprecated, but most of their methods are. For example:

• java.util.Date has methods like getYear(), getMonth(), and toGMTString() tagged with @Deprecated—these are notoriously error-prone (like getYear() returning the year minus 1900, which trips up almost everyone at some point).
• java.util.Calendar suffers from even more design flaws: its date-manipulation methods are verbose, months start at 0 (yes, Calendar.JANUARY = 0), and it’s not thread-safe at all.

The core classes stick around for backward compatibility (they’re still present in Java 21), but they’re strongly discouraged for any new work.

Does java.time (Java 8+) cover all functionality of java.util.Date? #

Absolutely—and then some. The java.time API (JSR 310) was built specifically to fix all the pain points of the old date-time classes:

• It uses immutable objects, so no unexpected side effects when working across threads.
• It has type-specific classes for every use case: LocalDate (date without time), LocalTime (time without date), ZonedDateTime (date+time with timezone), Instant (the exact equivalent of Date’s timestamp value), etc.
• Timezone handling is explicit and intuitive, unlike Calendar’s messy, hidden timezone logic.
• Parsing/formatting with DateTimeFormatter is thread-safe (a huge upgrade over SimpleDateFormat paired with Date).

You can also easily convert between java.util.Date and java.time objects (e.g., Date.from(instant) or date.toInstant()) if you need to bridge legacy code, so there’s no functionality gap.

Is there any reason to use java.util.Date/Calendar anymore? #

Only in legacy-specific scenarios:

• Maintaining old codebases: If you’re stuck working on a project written before Java 8 and can’t refactor everything at once, you’ll have to use them. But whenever possible, refactor small sections to use java.time—it’ll make the code way easier to maintain.
• Interacting with outdated libraries: Some older third-party tools still expect Date or Calendar as parameters. In these cases, convert between java.time objects and the old classes at the edge of your code, keeping the modern API in your core logic.

For new code, there’s zero good reason to use java.util.Date or java.util.Calendar. The java.time API is better in every way.

Should we completely avoid them? #

• For new code: Yes, 100%. Always reach for java.time classes first. They’ll save you from countless bugs related to timezone mix-ups, mutable state, and off-by-one month errors.
• For existing code: Avoid adding new usage of Date/Calendar. If you’re fixing bugs or extending the code, take the chance to refactor relevant parts to java.time—it’ll pay off in long-term maintainability. If refactoring isn’t feasible, be extra cautious (never share Calendar instances across threads, double-check month values, etc.).

内容的提问来源于stack exchange，提问作者Ondrej Bozek