Java GregorianCalendar lightweight

Question

Is the java.util.GregorianCalendar a lightweight object? In other words, does calling the constructor in a web application setting with each request extract nothing more than a trivial performance penalty, or does it pay to cache a copy of the object for shared use by the application?

Answer 1

You can improve the performance of GregoianCalendar by caching/sharing the TimeZone and Locale which are immutable.

Is the java GregorianCalendar a lightweight object?

If by lightweight you mean; like a balloon made of concrete. ;)

does calling the constructor in a web application setting with each request extract nothing more than a trivial performance penalty

Its can be relatively trivial compared to everything else you are doing. You can't know until you cpu profile the application.

does it pay to cache a copy of the object for shared use by the application

Only if you treat the objects as immutable (which may not be very useful)

Using a shared mutable GregorianCalendar could introduce bugs which are far worse than running a little bit slow.

BTW: I would consider using JodaTime. It is slight faster but generally better to use.

Answer 2

Use JODA datetime. It is added in also java 8.

Answer 3

java.time

The modern approach uses the java.time classes built into Java 8 and later. Avoid the troublesome legacy classes wherever possible.

Instead of GregorianCalendar, use ZonedDateTime.

Converting between legacy and modern

You can even convert, for inter-operating with old code. Call new methods added to the old classes.

ZonedDateTime zdt = myGregCal.toZonedDateTime() ;      // From legacy to modern.
GregorianCalendar gc = GregorianCalendar.from( zdt ) ; // From modern to legacy.

Thread-safety

One big problem with caching a GregorianCalendar object is that it is not thread-safe. By keep it around, you may generate exceptions or bad data at runtime by making unsafe calls.

In contrast, java.time uses immutable object. Instead of modifying some aspect of an existing object, a new object is generated instead. The java.time classes are designed to be thread-safe.

---

About java.time

The java.time framework is built into Java 8 and later. These classes supplant the troublesome old legacy date-time classes such as java.util.Date, Calendar, & SimpleDateFormat.

The Joda-Time project, now in maintenance mode, advises migration to the java.time classes.

To learn more, see the Oracle Tutorial. And search Stack Overflow for many examples and explanations. Specification is JSR 310.

Where to obtain the java.time classes?

• Java SE 8, Java SE 9, and later
  • Built-in.
  • Part of the standard Java API with a bundled implementation.
  • Java 9 adds some minor features and fixes.
• Java SE 6 and Java SE 7
  • Much of the java.time functionality is back-ported to Java 6 & 7 in ThreeTen-Backport.
• Android
  • Later versions of Android bundle implementations of the java.time classes.
  • For earlier Android, the ThreeTenABP project adapts ThreeTen-Backport (mentioned above). See How to use ThreeTenABP….

The ThreeTen-Extra project extends java.time with additional classes. This project is a proving ground for possible future additions to java.time. You may find some useful classes here such as Interval, YearWeek, YearQuarter, and more.