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

ChronoLocalDate generics difficult to use

    Details

    • Type: Bug
    • Status: Closed
    • Priority: P2
    • Resolution: Fixed
    • Affects Version/s: 8
    • Fix Version/s: 8
    • Component/s: core-libs
    • Labels:
    • Subcomponent:
    • Introduced In Version:
      8
    • Resolved In Build:
      b102
    • Verification:
      Verified

      Description

      The signature of ChronoLocalDate with a self type generic causes difficulties AFAICT in actually using the class.

      This code will not compile:

      {
        ChronoLocalDate<?> date = chrono.dateNow();
        date = process(date);
      }
      private <D extends ChronoLocalDate<D>> D processOK(D date) {
        return date;
      }

      It does work using a concrete type, such as FooDate.

      This seems like pretty basic usage of the API. What it would mean in practice is that no utility methods could be written stating that they return the same CLD type as the type that is input.

      Some advice is given suggesting that wildcards should be avoided in return types, but auto-casting may not be the result is the best solution for methods like dateNow().

      It should be considered that the best option may be to remove all generics from CLD/CLDT/CZDT even though that removes functionality from users of the concrete types. At least without the generics, they can be added in JDK 1.9 if a solution can be found.

      See JSR 310 GitHub issue #292: https://github.com/ThreeTen/threeten/issues/292

        Attachments

          Activity

            People

            • Assignee:
              rriggs Roger Riggs
              Reporter:
              rriggs Roger Riggs
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: