JDK-4209721 : RFE: Calendar is too difficult to subclass
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.util:i18n
  • Affected Version: 1.2.0
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: generic
  • CPU: generic
  • Submitted: 1999-02-08
  • Updated: 2002-06-26
  • Resolved: 2002-06-26
Related Reports
Duplicate :  
Description

Name: bb33257			Date: 02/08/99


Currently, java.util.Calendar is very difficult
to subclass.  There ends up being a huge amount of
boilerplate code that must be duplicated in each
subclass.  I found this out while implementing four
new calendar classes, which are available at
http://www.alphaWorks.ibm.com/formula/calendars.

The worst examples are the "add" and "roll" methods.
The vast majority of the code in these methods is
common to all subclasses.  Only subclasses that have
fields with weird behavior, e.g. Hebrew leap months,
need to do anything special in these methods.  Other
calendars (e.g. Islamic) would work fine with a
generic implementation.

We need to add generic implementations of "add" and
"roll", and perhaps a few other methods, to Calendar
so that subclasses can call them rather than creating
their own, identical, implementations of the methods.
The generic versions could be provided either as
default implementations of the current "add" and "roll"
methods (making them non-abstract), or as separate
"handleAdd" and "handleRoll" methods that subclasses
could call if needed.
(Review ID: 53908)

======================================================================

Comments
WORK AROUND Name: bb33257 Date: 02/08/99 Duplicate the roll and add code in each subclass. ======================================================================
11-06-2004

EVALUATION In general, add/roll methods should depend on an actual calendar system. If all calendar systems have common rules for add/roll, it should be possible to have a common subclass of Calendar that implements add/roll methods and to subclass it further for the actual implementation classes. masayoshi.okutsu@Eng 1999-08-11 Reopened and closing this as a duplicate of 4340168. ###@###.### 2002-06-26
11-08-1999