Primitive collections support breaks existing code

Aleksey Shipilev aleksey.shipilev at oracle.com
Mon Nov 19 08:23:20 PST 2012


On 11/19/2012 08:02 PM, Brian Goetz wrote:
> it will prefer IntFunction.  Probably best to update tests that
> currently map to a primitive but are intended to test reference streams
> cast to references.

In most of our tests, there is not provisioning yet on the
reference-vs-primitive. Some day we will have to split those up.

>>   1. Is there a timeline for skeleton implementations for IntStream? If
>> that would take longer than, say, a week, I would work that around in
>> the tests.
> 
> Depends what you mean by skeleton!  We've got filter/map/reduce already :)

Hmmm, nope? This fails:

    @Test
    public void test4() {
        Assert.assertEquals(
                Integer.valueOf(9),
                Arrays.asList("Foo", "BarBar", "BazBazBaz")
                        .stream()
                        .map(s -> s.length())
                        .reduce((l, r) -> (l > r ? l : r))
                        .get()
        );
    }

with:

java.lang.UnsupportedOperationException
  at java.util.stream.primitive.IntPipeline.reduce(IntPipeline.java:137)
  at net.openjdk.streams.StreamAPITest.test4(StreamAPITest.java:54)


> Yes, because you'd have to box anyway.  The idea is that primitive
> streams are primarily there for supporting reduction on primitives (sum,
> min, max, etc.)  There is a "boxed" op that gets you back to
> Stream<Integer>:
> 
>                   Arrays.asList("Foo", "Bar", "Baz")
>                           .stream()
>                           .map(String::length)
>                           .boxed()
>                           .into(new ArrayList<Integer>())

Yes, boxed() is nice and enough.

Thanks,
-Aleksey.



More information about the lambda-dev mailing list