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

          smarks Stuart Marks created issue -
          smarks Stuart Marks made changes -
          Field Original Value New Value
          Link This issue csr of JDK-8060192 [ JDK-8060192 ]
          smarks Stuart Marks made changes -
          Description
          Summary
          -------

          A concise description of the proposed change. The description should
          be one to two sentences long and written to be reusable in documents
          aggregating changes for a release.

          Problem
          -------

          A brief description of the problem, optionally including the
          motivation for developing a solution.

          Solution
          --------

          An overview of the solution. Alternative solutions may be discussed;
          links to rationale documents or review threads welcome to provide
          additional background to reviewers.

          Specification
          -------------

          The detailed changes. Acceptable normative formats include inline
          patches, attached webrevs, and attached specdiffs. The names of
          attached files are recommended to include a bug id. References to
          external webservers, such as http://cr.openjdk.java.net/, can be
          provided as informative supplements for the convenience of reviewers,
          but must be accompanied by a normative form of the specification
          directly associated with the CSR issue to satisfy archival purposes.

          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. This is easily
          accomplished with the toArray() method, which will create an Object array of the right
          size. Occasionally the caller desires an array of a particular component type instead
          of Object. This can be accomplished via the toArray(T[ ]) method. This lets the caller
          specify the array's component type. 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 but 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.

          Solution
          --------

          An overview of the solution. Alternative solutions may be discussed;
          links to rationale documents or review threads welcome to provide
          additional background to reviewers.

          Specification
          -------------

          The detailed changes. Acceptable normative formats include inline
          patches, attached webrevs, and attached specdiffs. The names of
          attached files are recommended to include a bug id. References to
          external webservers, such as http://cr.openjdk.java.net/, can be
          provided as informative supplements for the convenience of reviewers,
          but must be accompanied by a normative form of the specification
          directly associated with the CSR issue to satisfy archival purposes.

          smarks Stuart Marks made changes -
          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. This is easily
          accomplished with the toArray() method, which will create an Object array of the right
          size. Occasionally the caller desires an array of a particular component type instead
          of Object. This can be accomplished via the toArray(T[ ]) method. This lets the caller
          specify the array's component type. 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 but 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.

          Solution
          --------

          An overview of the solution. Alternative solutions may be discussed;
          links to rationale documents or review threads welcome to provide
          additional background to reviewers.

          Specification
          -------------

          The detailed changes. Acceptable normative formats include inline
          patches, attached webrevs, and attached specdiffs. The names of
          attached files are recommended to include a bug id. References to
          external webservers, such as http://cr.openjdk.java.net/, can be
          provided as informative supplements for the convenience of reviewers,
          but must be accompanied by a normative form of the specification
          directly associated with the CSR issue to satisfy archival purposes.

          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.

          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 provide 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.

          smarks Stuart Marks made changes -
          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.

          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 provide 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.

          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 provide 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.

          smarks Stuart Marks made changes -
          Attachment specdiff.0.zip [ 73951 ]
          smarks Stuart Marks made changes -
          Fix Version/s 10 [ 16302 ]
          Fix Version/s tbd_major [ 11972 ]
          Compatibility Risk minimal [ 19601 ]
          Compatibility Risk Description It's always possible that a default method could conflict with an existing method subclass of a subclass, but this seems unlikely.
          Interface Kind Java API [ 19803 ]
          Scope SE [ 19106 ]
          smarks Stuart Marks made changes -
          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 provide 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.

          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 provide 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.

          smarks Stuart Marks made changes -
          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 provide 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.

          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[&zwnj;]) 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 provide 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.

          smarks Stuart Marks made changes -
          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[&zwnj;]) 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 provide 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.

          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[&zwnj;]) 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[&thinsp;])
          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 provide the right size.
          Usually the caller will pass in an array constructor reference, e.g. `toArray(String[&zwnj;]::new)`.


          Specification
          -------------

          A new method `Collection.toArray(IntFunction<T[&thinsp;]>)` 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.

          smarks Stuart Marks made changes -
          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[&zwnj;]) 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[&thinsp;])
          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 provide the right size.
          Usually the caller will pass in an array constructor reference, e.g. `toArray(String[&zwnj;]::new)`.


          Specification
          -------------

          A new method `Collection.toArray(IntFunction<T[&thinsp;]>)` 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.

          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[&thinsp;]) 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[&thinsp;])
          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[&thinsp;]> 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 provide the right size.
          Usually the caller will pass in an array constructor reference, e.g. toArray(String[&thinsp;]::new).


          Specification
          -------------

          A new method Collection.toArray(IntFunction<T[&thinsp;]>) 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.

          smarks Stuart Marks made changes -
          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[&thinsp;]) 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[&thinsp;])
          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[&thinsp;]> 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 provide the right size.
          Usually the caller will pass in an array constructor reference, e.g. toArray(String[&thinsp;]::new).


          Specification
          -------------

          A new method Collection.toArray(IntFunction<T[&thinsp;]>) 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.

          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[&thinsp;]) 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[&thinsp;])
          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&lt;T[&thinsp;]> 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 provide the right size.
          Usually the caller will pass in an array constructor reference, e.g. toArray(String[&thinsp;]::new).


          Specification
          -------------

          A new method Collection.toArray(IntFunction&lt;T[&thinsp;]>) 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.

          bpb Brian Burkhalter made changes -
          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[&thinsp;]) 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[&thinsp;])
          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&lt;T[&thinsp;]> 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 provide the right size.
          Usually the caller will pass in an array constructor reference, e.g. toArray(String[&thinsp;]::new).


          Specification
          -------------

          A new method Collection.toArray(IntFunction&lt;T[&thinsp;]>) 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.

          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[&thinsp;]) 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[&thinsp;])
          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&lt;T[&thinsp;]> 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[&thinsp;]::new).


          Specification
          -------------

          A new method Collection.toArray(IntFunction&lt;T[&thinsp;]>) 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.

          bpb Brian Burkhalter made changes -
          Reviewed By Brian Burkhalter [ bpb ]
          smarks Stuart Marks made changes -
          Status Draft [ 10001 ] Finalized [ 10110 ]
          dbessono Dmitry Bessonov made changes -
          Link This issue relates to JCK-7309146 [ JCK-7309146 ]
          smarks Stuart Marks made changes -
          Compatibility Risk Description It's always possible that a default method could conflict with an existing method subclass of a subclass, but this seems unlikely. 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.
          alanb Alan Bateman made changes -
          Reviewed By Brian Burkhalter [ bpb ] Alan Bateman, Brian Burkhalter [ alanb, bpb ]
          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.
          smarks Stuart Marks made changes -
          Fix Version/s 11 [ 18723 ]
          Fix Version/s 10 [ 16302 ]
          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).
          darcy Joe Darcy made changes -
          Resolution Approved [ 10000 ]
          Status Finalized [ 10110 ] Closed [ 6 ]

            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: