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

Add default method <A> A[] Collection.toArray(IntFunction<A[]> generator)

    Details

    • Type: CSR
    • Status: Closed
    • Priority: P3
    • Resolution: Approved
    • Fix Version/s: 11
    • Component/s: core-libs
    • Labels:
      None
    • Subcomponent:
    • Compatibility Risk:
      minimal
    • Compatibility Risk Description:
      Hide
      It's always possible that a default method could conflict with an existing method subclass of a subclass, but this seems unlikely. The creation of overloads for toArray(T[ ]) and toArray(IntFunction) means that toArray(null) is now ambiguous, and thus this is a source incompatibility. Null is disallowed by both overloads, so this incompatibility seems minor. It does affect the JSR 166 TCK, however.
      Show
      It's always possible that a default method could conflict with an existing method subclass of a subclass, but this seems unlikely. The creation of overloads for toArray(T[ ]) and toArray(IntFunction) means that toArray(null) is now ambiguous, and thus this is a source incompatibility. Null is disallowed by both overloads, so this incompatibility seems minor. It does affect the JSR 166 TCK, however.
    • Interface Kind:
      Java API
    • Scope:
      SE

      Description

      Summary

      Add a method that allows the caller to specify the type of an array to receive the contents of a collection, while letting the collection specify the size of the array to be created.

      Problem

      A common task is to transfer the contents of a Collection to an array. The toArray() method will create an Object array of the right size. The caller can specify the array's component type using the toArray(T[ ]) method. However, in general, the caller doesn't know the correct size to allocate. The semantics are that if the array is too short, the toArray(T[ ]) method will allocate an array of the correct size and with the same component type. Thus toArray(new Foo[0]) will always create a right-sized array with component type Foo. This works, but it is quite roundabout. It also (usually) creates a useless zero-sized array, though that usually isn't a big deal.

      Solution

      Add a new API toArray(IntFunction<T[ ]> generator). The caller passes in a function that takes an int and creates an array of the desired component type with that size. This lets the caller specify the component type and the Collection provides the right size. Usually the caller will pass in an array constructor reference, e.g. toArray(String[ ]::new).

      Specification

      A new method Collection.toArray(IntFunction<T[ ]>) is added. The other toArray() overloads' specifications have some text adjusted and migrated into API Note sections. This has the side effect on the corresponding methods in AbstractCollection, where the API Note text is no longer inherited. See attached specdiff for details.

        Issue Links

          Activity

          Hide
          darcy Joe Darcy added a comment -

          Unless there is a compelling reason to get this into 10, I'd feel more comfortable if this went in at the start of JDK 11.

          Show
          darcy Joe Darcy added a comment - Unless there is a compelling reason to get this into 10, I'd feel more comfortable if this went in at the start of JDK 11.
          Hide
          smarks Stuart Marks added a comment -

          OK to postpone to 11.

          Show
          smarks Stuart Marks added a comment - OK to postpone to 11.
          Hide
          darcy Joe Darcy added a comment - - edited

          A pedant might note "variables have types and objects have classes," but the discussion of such distinctions is not done consistently in the API docs and the phrase "runtime type" while informal leads the reader in the right direction.

          Voting to approve for 11 (with the @since tags updated to 11).

          Show
          darcy Joe Darcy added a comment - - edited A pedant might note "variables have types and objects have classes," but the discussion of such distinctions is not done consistently in the API docs and the phrase "runtime type" while informal leads the reader in the right direction. Voting to approve for 11 (with the @since tags updated to 11).

            People

            • Assignee:
              smarks Stuart Marks
              Reporter:
              psandoz Paul Sandoz
              Reviewed By:
              Alan Bateman, Brian Burkhalter
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: