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

LocalDate.isEra() should return IsoEra not Era


    • 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:


      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.




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


              • Created: