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

LocalDate.isEra() should return IsoEra not Era

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: P4
    • Resolution: Fixed
    • Affects Version/s: 8
    • Fix Version/s: 9
    • Component/s: core-libs
    • Labels:
    • Subcomponent:
    • Resolved In Build:
      b94

      Description

      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.

        Attachments

          Activity

            People

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

              Dates

              • Created:
                Updated:
                Resolved: