Thanks for having me!
In my introductory post, I was asked how my book compares to Pierre-Ives Saumont's "Functional Programming with Java", so I am trying to answer that now.
I think the main difference is already shown in its title/subtitle, highlighting the book's different approach to its topics.
The book approaches its topics primarily from the
Java side and moves towards FP, not vice versa.
That means it builds upon the available tools in the JDK and shows how to use them to augment your code gradually, not replace it with functional techniques and concepts, so you can enjoy the best of both OO and FP.
Looking at functional programming concepts and techniques from an isolated point of view, everything is quite awesome.
Topics like persistent data structures, reactive programming, or state management with actors, are all great solutions.
So many things are way easier to do than before in imperative or OO code.
However, many Java devs, myself included, work with existing projects, code bases, and dependencies living in an imperative or OO world.
We usually can't switch to another paradigm for core features or change the whole architecture because it is supposed to be a "better" solution.
Even if we could, most of the time, you still shouldn't without a clear need to do so.
That's why I try to approach the functional topics from the point of view of a more "typical" Java developer wanting to improve their code with functional concepts and techniques.
My reasoning for doing so is simple.
Once, I read a book about FP in Java that intentionally ignored Streams and built its own equivalent.
That's actually a great way to learn the why and how of declarative data processing, and there is much to learn from such content.
But on the other hand, how often do you really implement such a feature in a "real" project yourself? It feels a little bit like a case of "not invented here" syndrome.
I'm guilty of that myself, don't get me wrong, but I believe that using the tools already available often triumphs over using a dependency or, even worse, implementing it yourself.
My point is that using non-JDK tools always adds responsibilities, long-term commitments, and requires a mental overhead that you might even unwillingly force onto others.
That's why the book introduces functional concepts, techniques, and the available tools in the JDK in detail, including ~50 figures.
This allows the reader to develop a "functional mindest" that's useful regardless of the chosen paradigm, even in a more OO/imperative-akin language like Java, opening up a new world without completely transforming your code base.