Class Calendar

All Implemented Interfaces:
Serializable, Cloneable, Comparable<Calendar>
Direct Known Subclasses:
GregorianCalendar

@Deprecated public abstract class Calendar extends GregorianCalendar
Deprecated.
Transitional scaffolding produced by the import-swap. It keeps migrated Calendar code running with the right zone; hand-written and stage-3 code should use java.time (e.g. LocalDate/ZonedDateTime with com.vaadin.swingbridge.surrogates.BrowserTimeZone.get()) or com.vaadin.swingbridge.surrogates.SHelper, which are immutable and ZoneId-consistent.
Import-swap emulator for Calendar (java.util.Calendar → vaadinx.util.Calendar). Hosts the getInstance(...) factories; the concrete work is done by GregorianCalendar, which getInstance returns (matching the JDK, where Calendar.getInstance() hands back a GregorianCalendar in the common locales).

Why this exists. On the desktop one JVM serves one user, so Calendar.getInstance() / new GregorianCalendar(...) pick up TimeZone.getDefault() — which is the user's zone. On the server the default is the server's zone, so a migrated cal.set(y, m, d); cal.getTime() silently computes the wrong instant (server midnight, not the user's). This emulator defaults construction to the user's browser zone instead, via EmulatorContext.currentTimeZone() — reusing the same resolution the SimpleDateFormat emulator uses: browser zone on a UI thread (throwing SD_browser_timezone if BrowserTimeZone.fetch() was never called), the propagated zone on a background thread carrying an EmulatorContext, or the server default (with a WARN) on a bare background thread. An explicitly supplied TimeZone always wins.

Not a facade — a thin zone-defaulting subclass. Unlike the SimpleDateFormat emulator (which routes through a hidden per-session backing), this holds no extra state and overrides no behavior beyond the construction-time zone: every get/set/add/roll is inherited GregorianCalendar field math, unchanged. The returned object is a plain, thread-confined Calendar.

It does NOT make a shared Calendar thread-safe. A Calendar stashed in a static/shared field and mutated from multiple threads is unsound on a multi-user server — as it already was racy on the desktop, only masked by single-threaded EDT use. The migration answer for that shape is to unshare it (construct one per use); it is flagged for manual fixing, not silently emulated. This emulator targets the dominant one-off idiom.

The zone is applied via TimeZone.getTimeZone(java.time.ZoneId) — the same arithmetic the DatePicker-backed surrogates convert with, so a date built here shows its own day in a picker in every year, pre-1900 included.

Emulator-only — no surrogate; not a Component (D_timer_swingworker sibling of SimpleDateFormat / SwingWorker).

See Also:
  • Constructor Details

    • Calendar

      protected Calendar()
      Deprecated.
    • Calendar

      protected Calendar(TimeZone zone)
      Deprecated.
    • Calendar

      protected Calendar(Locale aLocale)
      Deprecated.
    • Calendar

      protected Calendar(TimeZone zone, Locale aLocale)
      Deprecated.
  • Method Details

    • getInstance

      public static Calendar getInstance()
      Deprecated.
    • getInstance

      public static Calendar getInstance(TimeZone zone)
      Deprecated.
    • getInstance

      public static Calendar getInstance(Locale aLocale)
      Deprecated.
    • getInstance

      public static Calendar getInstance(TimeZone zone, Locale aLocale)
      Deprecated.