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