Initial prototype for BiStream

Doug Lea dl at
Sat Apr 21 10:08:56 PDT 2012

On 04/18/12 18:39, Mike Duigou wrote:
> Hello all;
> I've committed an initial prototype for Bi-Value streams aka MapStream.

(It would have been helpful to give the hint that these are
currently hiding inside java.lang.Iterable!)

I think the left/right terminology in Bi forms is a little odd.
Too odd.
Plus there's no obvious place to go for Tri forms, and so on. "up"?

More common would be fst/snd. Or I suppose, first/second.

> There's a big question lurking in the implementation involving
> boxing/unboxing of BiValue<L,R>  as used by the BiBlock, BiMapper and
> Predicate. In some cases using the single param functional interfaces, ie.
> Predicate<BiValue<L,R>>  is more convenient or efficient than using
> BiPredicate<L,R>. The source data isn't always a Map though and elements
> might not already be stored in BiValues though. In these cases adding boxing
> would be a real cost.

Yeah. Packing/boxing on each method call is not going to win any friends
(especially when the call itself is itself likely to box/pack/unbock/etc).
The history of JDK classes that initially assumed that this was
not going to be a serious problem is not a pretty one. (For a random
old example, someone's initial version on WeakHashMap that required
construction of a Weak ref on each get() was too awful to
ever actually use.) Hoping that it will somehow magically come out
differently this time doesn't seem too appealing.

On the other hand, if these are carefully enough done, and
if first-rate tuple/struct support ever does make it into Java,
then in the long run, using tuples here could be the most
efficient way to do it.

So what do you with a decision that is in the short run a
BIG performance loss but in the long run is possibly a small
performance win, and in some people's minds, a nicer API?

The best answer might be a variant of my usual stance on all
this stuff: that it is OK to let you folks continue
to find the most defenseible APIs for the FP-friendly side of this,
and all will end up well if I also put into place highly efficient
pre-loop-fused, possibly-mutative, etc., direct methods in
ConcurrentHashMap and BetterArrayList, in part as a safeguard
to avert disaster. Maybe someday compilers/JVMs will figure out to
translate into these or even better forms. But in the mean time there
will still be a teachable path  for users who need/want it.


More information about the lambda-dev mailing list