Type safety bug for Spliterators.spliterator

Paul Sandoz paul.sandoz at oracle.com
Tue Feb 25 05:20:30 PST 2014


On Feb 24, 2014, at 10: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.

Yeah, that's it. In hindsight I think we set a bad example of convenience over safety, but too late to do anything about it now :-( 


> (Why are these in two separate places anyways?)


The array receiving factory methods on Spliterators are for advanced use, especially for splitting where an array may represent a sub-set or prefix of covered elements from a non-array source, hence the "additionalCharacteristics" parameter. Most developers will never need to use these methods.

Paul.


More information about the lambda-dev mailing list