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

Brian Goetz 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 mailing list