Loose end: zip

Joe Bowbeer joe.bowbeer at gmail.com
Thu Jun 6 15:58:25 PDT 2013

I don't think I have anything to add to what I already said: zip is an
expressive, useful tool.

Java programmers effectively use maps of maps, and maps of lists, and lists
of maps, and all kinds of inefficient things.

Originally, Java's biggest advantage was its increased productivity.  That
one advantage can make up for lots of little disappointments.

I definitely don't want to have to search for a zip snippet somewhere
(e.g., in Fugue?).  A basic tool like zip is not something I would look for
in an extension library.

Regarding the no-primitive versions, I think the consensus was to live with

On Thu, Jun 6, 2013 at 12:49 PM, Brian Goetz <brian.goetz at oracle.com> wrote:

> Still feeling kind of YAGNI on zip, for the reasons cited in the message
> below, plus:
>  - No primitive versions (would require new SAMs)
>  - Hard to parallelize
>  - Multiple ways to deal with streams of different length; we pick one
> Might this be something best provided by some other library than the JDK?
>  Or as a code example somewhere people can crib from to roll their own?
> On 5/1/2013 5:10 PM, Brian Goetz wrote:
>> Right, but the question is, how badly can we implement it and have it
>> not be worse than nothing?  And, with the current performance
>> characteristics (new object per element), are we below that threshold?
>> My problem is the same as with flatMap -- these are idioms from other
>> languages that *translate poorly* to Java because of the lack of tuples
>> and other structural types.  (The flatMap we got left with -- which I
>> reluctantly supported as the lesser of evils -- is, coincidentally, the
>> only other stream operation that has allocation-per-element.)  At what
>> level of translation-fidelity loss do we say "yeah, it works great in
>> that other environment, but too much is lost in translation"?
>> I don't doubt the utility of zip, or the fact that Joe-alikes will want
>> it, and would be bummed to not find it.  My question is whether the
>> crappy zip we can have is better than no zip.  (Where better doesn't
>> just mean "better than nothing", but carries its weight.)

More information about the lambda-libs-spec-observers mailing list