Before we close out this conversation, it is also worth noting that it is often important to develop backwards.
If you are working on an open source library or are otherwise unsure about the skill of the developer reading
your code, then you need to take special care. Not every Java developer has read this topic yet, and so this
new post-functional programming paradigm can seem very strange to them. For instance, this line of code
recently came up in a project that I was working on:
(impl == null ? defaultImpl : impl).apply(arg);
If you know that impl and defaultImpl are both Function values, then it is very easy to understand
what is going on there. On the other hand, it looks somewhat bizarre. It looks even stranger in the middle of
a series of stream transformations. Even simple forEach calls can throw people for a loop sometimes.
Given that, care needs to be taken to be as clear as possible. If you are going to work with developers
who may not be familiar with post-functional programming, be nice to them. Implement interfaces for the
arguments where you expect a lambda, so that they can pass in interface implementations and have an
obvious place to look for documentation. Limit the number of lambdas that you take in a method, because
having too many lambdas results in a maze of callbacks. Generally, be very clear that the code you are
writing really is clearer and easier for them to read. Not only will this reduce the number of questions
(and buggy changes!) that you are going to get, but it creates an opportunity for those developers to learn
and move along.