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 14:59:17 PDT 2013

The minimum I can't absolutely live without is a Turing machine, so don't mind me. It's just that is it the 3rd time that something I really like is removed from the stream API.

I hope they weren't the only three things you liked.

For the record, the rationales are:

  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.)

  2. MapStream. Again, trying to incorporate streams of different arities within the implementation and API was putting so much stress on the design that we were unable to move forward at an acceptable rate of progress. By removing this as a requirement, we were able to progress much more rapidly on the stream APIs we do have. After 8, we will look at whether it is possible to restore this functionality.

  3. FlatMapper. We ran numerous focus groups and hack days, and the feedback was universal on "this isn't ready." Better to leave it out than get it wrong. As it stood, it was adding a great deal of API surface area for something few people could understand and even fewer could justify using. If you're one of those few, congratulations -- you're not the target audience :)

Our goal has been to get what we deliver right, rather than deliver a bunch of stuff, some of which is right. Sometimes that means a favorite feature is deemed not ready for prime time.

More information about the lambda-dev mailing list