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.

        Activity

        Hide
        rriggs Roger Riggs added a comment -
        This change is only possible because the getEra method is coming from an interface so that the implementation class can return a more specific type using a covariant override such as IsoEra rather than Era.

        This binary compatibility issue in the change of the return type is addressed by the insertion of a bridge method by javac.

        javap -cs java.time.LocalDate:
        ...
         public java.time.chrono.Era getEra();
            Signature: ()Ljava/time/chrono/Era;
            flags: ACC_PUBLIC, ACC_BRIDGE, ACC_SYNTHETIC
            Code:
              stack=1, locals=1, args_size=1
                 0: aload_0
                 1: invokevirtual #251 // Method getEra:()Ljava/time/chrono/IsoEra;
                 4: areturn

        Show
        rriggs Roger Riggs added a comment - This change is only possible because the getEra method is coming from an interface so that the implementation class can return a more specific type using a covariant override such as IsoEra rather than Era. This binary compatibility issue in the change of the return type is addressed by the insertion of a bridge method by javac. javap -cs java.time.LocalDate: ...  public java.time.chrono.Era getEra();     Signature: ()Ljava/time/chrono/Era;     flags: ACC_PUBLIC, ACC_BRIDGE, ACC_SYNTHETIC     Code:       stack=1, locals=1, args_size=1          0: aload_0          1: invokevirtual #251 // Method getEra:()Ljava/time/chrono/IsoEra;          4: areturn
        Hide
        hgupdate HG Updates added a comment -
        URL: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/d6eeea558b1f
        User: rriggs
        Date: 2015-11-17 16:07:03 +0000
        Show
        hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/d6eeea558b1f User: rriggs Date: 2015-11-17 16:07:03 +0000
        Hide
        hgupdate HG Updates added a comment -
        URL: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/d6eeea558b1f
        User: lana
        Date: 2015-11-25 21:18:22 +0000
        Show
        hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/d6eeea558b1f User: lana Date: 2015-11-25 21:18:22 +0000

          People

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

            Dates

            • Created:
              Updated:
              Resolved: