Type safety bug for Spliterators.spliterator

[Zhong Yu]

T[] to Spliterator<T> is not general enough, we'll need T[] to
Spliterator<S> where S is a subtype of T. Caller guarantees that the
T[] array contains only S elements.

So we might want something like

    <T, S extends T> Spliterator<S> spliterator(T[] array, int)

Unfortunately this doesn't work either (your code will still compile),
since T can always be inferred as Object.

Zhong Yu





On Mon, Feb 24, 2014 at 3:23 PM, Martin Buchholz <martinrb at google.com> wrote:
> The following program compiles, but IMO clearly should not:
>
> import java.util.*;
> public class UncheckedSpliterator {
>     public static void main(String[] args) throws Throwable {
>         String[] stooges = { "Larry", "Moe", "Curly" };
>         Spliterator<Integer> s = Spliterators.spliterator(stooges, 0);
>     }
> }
>
> The signature of Arrays.spliterator is
> public static <T> Spliterator<T> spliterator(T[] array)
> while the signature of Spliterators.spliterator is
> public static <T> Spliterator<T> spliterator(Object[] array,
>                                                  int
> additionalCharacteristics)
> The second signature should take a T[] like the first,
> even though the second signature happens to be convenient for collections
> class implementers.
> (Why are these in two separate places anyways?)
>