hg: lambda/lambda/jdk: Remove FlatMapper and relevant flatMap variants; migrate to flatMap(e -> stream)
brian.goetz at oracle.com
Tue Apr 9 16:25:39 PDT 2013
>> 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.
More information about the lambda-dev