Re: Type safety bug for Spliterators.spliterator

[Timo Kinnunen]

Regarding expectations, once this type hole has been opened, is the expectation that it is caught at runtime? 


System.out.println should be able to println anything thrown at it and forEachRemaining accepts a Consumer of ? super T which can always be Object, so what are these expected to do at runtime:



String[] stooges = {"Larry", "Moe", "Curly"};


Spliterator<Integer> s1 = Spliterators.spliterator(stooges, 0); 

s1.forEachRemaining(System.out::println);


Spliterator<Integer> s2 = Spliterators.spliterator(stooges, 0);

s2.forEachRemaining(o -> System.out.println(o));












-- 
Have a nice day,
Timo.

Sent from Windows Mail





From: Martin Buchholz
Sent: ‎Tuesday‎, ‎February‎ ‎25‎, ‎2014 ‎22‎:‎12
To: Paul Sandoz
Cc: lambda-dev at openjdk.java.net





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

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.