Details
-
Type:
Bug
-
Status: Closed
-
Priority:
P4
-
Resolution: Duplicate
-
Affects Version/s: 5.0
-
Fix Version/s: None
-
Component/s: core-libs
-
Labels:
-
Subcomponent:
-
CPU:x86
-
OS:windows_xp
Description
FULL PRODUCT VERSION :
java version "1.5.0_05"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05)
Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing)
ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows XP [Version 5.1.2600]
A DESCRIPTION OF THE PROBLEM :
To take full advantage of the code in Calendar, a concrete sub-class needs read-access to Calendar's stamp field. This access is required by a sub-class
in order to determine which field amongst competing fields (e.g
HOUR/AM_PM vs. HOUR_OF_DAY) to use in computeTime ().
Calendar should provide a new protected method [e.g. getStamp (int field)] for examining the value of the stamp.
This problem has existed since (at least) JDK 1.3.1.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Not Applicable.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Ability to derive a Calendar sub class without reimplementing most of Calendar's logic.
ACTUAL -
Inability to derive a concrete class from Calendar without reimplementing most of its logic.
REPRODUCIBILITY :
This bug can be reproduced always.
CUSTOMER SUBMITTED WORKAROUND :
Maintaining local version of Calendar with getStamp () method.
java version "1.5.0_05"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05)
Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing)
ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows XP [Version 5.1.2600]
A DESCRIPTION OF THE PROBLEM :
To take full advantage of the code in Calendar, a concrete sub-class needs read-access to Calendar's stamp field. This access is required by a sub-class
in order to determine which field amongst competing fields (e.g
HOUR/AM_PM vs. HOUR_OF_DAY) to use in computeTime ().
Calendar should provide a new protected method [e.g. getStamp (int field)] for examining the value of the stamp.
This problem has existed since (at least) JDK 1.3.1.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Not Applicable.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Ability to derive a Calendar sub class without reimplementing most of Calendar's logic.
ACTUAL -
Inability to derive a concrete class from Calendar without reimplementing most of its logic.
REPRODUCIBILITY :
This bug can be reproduced always.
CUSTOMER SUBMITTED WORKAROUND :
Maintaining local version of Calendar with getStamp () method.
Attachments
Issue Links
- duplicates
-
JDK-4209296 (cal) API: Calendar subclassing is broken since 1.2
-
- Resolved
-