Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8072746

LocalDate.isEra() should return IsoEra not Era

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: P4 P4
    • 9
    • 8
    • core-libs
    • 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.

            ntv Nadeesh Tv
            scolebourne Stephen Colebourne
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: