Type safety bug for Spliterators.spliterator

[Paul Sandoz]

On Feb 25, 2014, at 9:12 PM, Martin Buchholz <martinrb at google.com> wrote:

> 
> 
> 
> On Tue, Feb 25, 2014 at 5:20 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> 
> 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 :-(
> 
> 
> Sad that things like this are still not considered fixable, before jdk8 fcs ...
> 

I know, but the bar is very high now. Given my experience of two recent re-spins including flatMap docs and Comparator method signature change this one is likely to get rejected.

There might be some hope if there is a re-spin for some other issue (but still IIUC this issue will require updates to other areas like JCK signature tests so even if piggy-backing it may not be a free lunch). I don't know if that is gonna happen, but will check.


> The lack of type safety isn't so bad, except that Java programmers have a very strong expectation that the compiler will find all such coding mistakes.


Agreed.

Paul.