Primitive collections support breaks existing code
Brian Goetz
brian.goetz at oracle.com
Mon Nov 19 08:02:21 PST 2012
> I understand primitive streams are still in flux, but those are breaking
> the existing test/benchmark code since lambdas are getting inferenced to
> primitive interfaces, and implicitly moving to primitive streams (which
> is an awesome idea when it is completed :)).
I think the overload of map(Function) and map(IntFunction) is here to
stay. The compiler will try and avoid boxing/unboxing, so if you have:
map((Integer i) -> i)
it will prefer Function, whereas if you have
map((Integer i) -> i.intValue())
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.
> Down to specific questions:
>
> 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 :)
> 2. Does IntStream.into() omitted for the reason? This does not compile:
>
> @Test
> public void test3() {
> Assert.assertEquals(
> Arrays.asList(3, 3, 3),
> Arrays.asList("Foo", "Bar", "Baz")
> .stream()
> .map((s) -> s.length())
> .into(new ArrayList<Integer>())
> );
> }
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>())
(or you could box implicitly in the map:
Arrays.asList("Foo", "Bar", "Baz")
.stream()
.map(s -> (Integer) s.length())
.into(new ArrayList<Integer>())
More information about the lambda-dev
mailing list