All 15 Java Date & Time API (java.time) questions
More in Java Date & Time API (java.time)
What is the significance of storing date-time values in UTC in a database or when transmitting between systems, rather than storing them in a specific local timezone? How would you determine whether a given year is a leap year, and calculate the number of days in a specific month, using the java.time API's built-in support rather than hand-writing this classic calendrical logic? How does the Instant class represent a point in time, and how does it differ fundamentally from ZonedDateTime in terms of what it actually represents and how it should be used? How would you correctly handle daylight saving time (DST) transitions when performing date-time arithmetic with ZonedDateTime, and what specific pitfalls exist around the 'spring forward' and 'fall back' transitions? How would you implement a custom TemporalAdjuster to calculate business-specific date logic (like 'the next business day, skipping weekends and holidays')? How would you correctly serialize and deserialize java.time types (like LocalDateTime or ZonedDateTime) to/from JSON using a library like Jackson, and what common configuration pitfalls arise? How would you implement a recurring event scheduling system that correctly handles both fixed-instant recurrence (every exactly 24 hours) and calendar-based recurrence (every day at 9 AM local time), given these have meaningfully different behavior across DST transitions?
Advertisement
Back to results for “Connectivity”
Java › Java Date & Time API (java.time)

How would you convert between the legacy java.util.Date/Calendar classes and the modern java.time API when working with older libraries or APIs that still require the legacy types?

Advanced

Answer

The java.time API provides explicit conversion bridge methods specifically for interoperating with legacy code that hasn't been (or can't easily be) migrated: Date.from(Instant) and date.toInstant() convert between Date and Instant; GregorianCalendar.from(ZonedDateTime) and calendar.toZonedDateTime() convert between Calendar and ZonedDateTime -- these bridge methods let you isolate legacy-API interop to specific boundary points in a codebase (like a third-party library's method signature still requiring a Date parameter) while using the modern, safer java.time types throughout the rest of your own code, converting only at the necessary boundary rather than propagating legacy types more broadly than necessary.
// Modern code internally uses Instant
Instant modernInstant = Instant.now();

// Convert to legacy Date only at the boundary where a legacy API requires it
Date legacyDate = Date.from(modernInstant);
legacyLibraryMethod(legacyDate);  // some older API that still requires java.util.Date

// Convert a legacy Date received FROM an old API back to modern Instant
Instant convertedBack = legacyDate.toInstant();
Real-world example A codebase primarily using modern java.time types throughout still needs to call a third-party reporting library's API that only accepts java.util.Date parameters, using Date.from(instant) specifically at that narrow integration boundary while keeping the rest of the application's own code entirely on the safer, immutable java.time types.

Common follow-ups: Why do these specific bridge methods exist only on Date/Calendar and their java.time counterparts, but not for the even older java.sql.Date/Timestamp classes as directly?;What's the recommended approach if a legacy library's API can't be avoided long-term and is used extensively throughout a codebase?

Build Tools: Maven & Gradle;JDBC & Database Connectivity
All 15 Java Date & Time API (java.time) questions