hg: lambda/lambda/jdk: Remove FlatMapper and relevant flatMap variants; migrate to flatMap(e -> stream)

[Brian Goetz]

>> 1.  Pluggable Op API.  It became apparent very early on that this was not
>> going to converge within the timeframe needed, and that we were better off
>> focusing on the parts that were going to converge.  Finishing this and
>> including it in Java 9 is a high priority.  (By the way, had we committed
>> to any of the forms from, say, more than two weeks ago, we would have
>> nailed ourselves into a corner but good.  So this was clearly the right
>> decision, it was just not ready to stabilize.)
>
> Changing stuff, even fundamentally, even late in the game, is fine for me.
> What bother me is this increasing feeling of, hmm, claustrophobia when I try
> to do something with streams.  I had plans for an I/O stream source where some
> parts of the pipeline can be removed and pushed closer to the hardware.  That
> would have been cool.

Right.  We chose to keep the ability to give that to you eventually 
rather than give you something crappy now that almost but not quite 
gives you that (and never can be extended.)  That feeling of 
claustrophobia -- which I totally understand -- has already yielded 
benefits that you might not have seen.  For example, even thought this 
was not the intent, each feature we have taken away has led to 
performance improvements, some of them significant, which often is 
enabled by pruning the 2% use cases.  Everyone benefits from this, even 
the 2% of the users that also suffer somewhere else.  These are 
generally good trades.

Our focus for 8 is providing the right user-level abstractions for 
people who want to do typical queries and transformations on 
Collections.  The rocket-scientist applications necessarily must take a 
back seat until we get the former right.