-
Bug
-
Resolution: Fixed
-
P4
-
8
-
b94
The 'LocalDate.getEra()' method is declared to return 'Era', as inherited from 'ChronoLocalDate'. In all other date classes, such as 'JapaneseDate' or 'HijrahDate', the method signature is overridden to return the correct era type for the calendar system. Thus 'HijrahDate.getEra()' returns 'HijrahEra' and so on. 'LocalDate.isEra()' should be defined to have a return type of 'IsoEra', but this is not the case.
Changing the return type to be more specific should be OK for a major release, but unlikely to be OK for backporting. It can be argued to be within the existing spec, as the spec indicates that the result must be == comparable to the constants in 'IsoChronology', which can only reasonably be interpreted as meaning 'IsoEra'.
The Javadoc of them method is also inaccurate. It says "The returned era will be a singleton capable of being compared with the constants in {@link IsoChronology} using the {@code ==} operator." This is clearly wrong and refers to an older version of IsoChronology (before 'IsoEra' was a public class). If the method return type is changed, the sentence can simply be removed.
Changing the return type to be more specific should be OK for a major release, but unlikely to be OK for backporting. It can be argued to be within the existing spec, as the spec indicates that the result must be == comparable to the constants in 'IsoChronology', which can only reasonably be interpreted as meaning 'IsoEra'.
The Javadoc of them method is also inaccurate. It says "The returned era will be a singleton capable of being compared with the constants in {@link IsoChronology} using the {@code ==} operator." This is clearly wrong and refers to an older version of IsoChronology (before 'IsoEra' was a public class). If the method return type is changed, the sentence can simply be removed.