Venkat Subramaniam

Hi Everyone,

Thank you to each and everyone for your wishes, questions, and discussions.
Best wishes for a wonderful experience learning and applying Java 8.
Have fun.

Regards,

Venkat

Hi Sean,

There's no direct correlation between immutability and efficiency.

An immutable data structure can be efficient or largely inefficient when it comes to transforming from one collection of values to another. In Clojure, efficiency comes from the use of Tries and other highly efficient data structures.

In Java 8, efficiency comes from streams. That's one of the reason for the separation of stream and collect. Streams perform lazy evaluations and also tactfully postpone the creation of the target data structure.

If efficiency is the main concern, it would be good to run some benchmarks to measure the performance and then come to conclusion if one is better than the other.

The lack of immutable data structure is a concern, however, not from the point of view of efficiency, but from the point of view of errors that may arise due to inappropriate shared mutability. The anti-pattern of trying to update a data structure from within lambdas is something programmers are going to do and then learn to avoid.

Thanks

Venkat

The second parameter says after performing the grouping, instead of collecting the pairs for each group, instead collect the (in this example, the second) specific value from within the pair. Without the mapping, we will get a Map<Integer, List<Pair>> instead of Map<Integer, List<Integer>>.

Hi Piet,

Here's the code for the transformation:

Map<Integer, List<Integer>> result = values.stream() .collect(groupingBy(Pair::getFirst, mapping(Pair::getSecond, toList())));

Here is the complete code example:

import java.util.*; import static java.util.stream.Collectors.*; public class Sample { public static void main(String[] args) { class Pair { public final int first; public final int second; public int getFirst() { return first; } public int getSecond() { return second; } public Pair(int firstValue, int secondValue) { first = firstValue; second = secondValue; } } List<Pair> values = Arrays.asList( new Pair(1, 1), new Pair(1, 2), new Pair(1, 3), new Pair(2, 10), new Pair(2, 20), new Pair(2, 30), new Pair(3, 100), new Pair(3, 200), new Pair(3, 300) ); Map<Integer, List<Integer>> result = values.stream() .collect(groupingBy(Pair::getFirst, mapping(Pair::getSecond, toList()))); System.out.println(result); } }

The book does not get into this discussion.

This is certainly a concern if we create a divide in team where some people stays stagnant and others learn and move forward.

Given that almost all mainstream languages now support functional style, it is to great disadvantage to developers if they do not
become familiar with the style. It will largely limit there ability to program effectively in just about any language moving forward.

Over time, as we all get more familiar with the style, we will transition. In my observation, most programmers are fairly good at such
transition, when a language evolves. C# has gone through exactly this cycle, only a few years ahead.

Hi Stevens,

Java will never be or become a true functional programming language. The imperative style and mutability is far too engrained in it.
It certainly has another style to program and the onus is on us to use that style judiciously in ways we can gain.

Several languages have done this. Smalltalk, Ruby, Scala,... there is a long list of languages that support both imperative and functional style.
I like having that flexibility and the wisdom to choose.

One of the tenets of FP is immutability. We do not mutate and especially mutate shared state. If we mutate state and cause side effects,
it will mess up several things that are possible in FP - referential transparency, lazy evaluations, potential concurrency and re-orderings.

Please see the link below:

"We should use extra caution not to mix mutability, shared state, and functional style.-->Can you just give me a rough example on this statement "

from Discussion on FP and mutability

If the goal is to transform one list to another, then do the transformation first, using map, keeping the transformatio operation pure. Then convert the
abstraction of stream to a concrete collection, like list.

Hi Bairava, you may find this link useful: Presentation video

David, no in this book I focus only on Java 8. I've written books on Scala and Groovy, and also use quite a few other languages on the JVM on a regular basis. I do not see a reason to compare with one and not the other languages in a book like this. My objective for writing this book is to help Java programmers get up to speed on this newer facilities and so have kept it topics spot on that.

Deepak Lal wrote:... Can i get to see such examples in your book

Yes and you may also download the code examples from Source code from the book.

Pho Tek wrote:However, lambdas blocks that throw Checked Exceptions do not fit very well into the FP paradigm.

Code that throws exception in general does not fit nicely into FP, that's why truly functional languages have other control mechanisms (monads) to deal with exceptions.

Having said that, checked exceptions borderline anti patterns in Java for many reasons and that, unfortunately, will continue to haunt us in the future.

Hi Harsha, this book does not assume any prior knowledge of lambda expression.

I think that Chris's response is pretty right on from all angles. Thanks.

We should use extra caution not to mix mutability, shared state, and functional style.-->Can you just give me a rough example on this statement


Here's one example, I've seen beginners of FP do this:

List<Integer> values = Arrays.asList(1, 2, 3, 4, 5, 6); List<Integer> doubled = new ArrayList<>(); values.forEach(e -> doubled.add(e * 2)); System.out.println(doubled);

In the above code, from within the lamba expression we're mutating the ArrayList. This one is quite easy to fix.


List<Integer> values = Arrays.asList(1, 2, 3, 4, 5, 6); List<Integer> doubled = values.stream() .map(e -> e * 2) .collect(toList()); //import static java.util.stream.Collectors.toList; System.out.println(doubled);

In general we should avoid the temptation to mutate a variable from within a lambda expression. In other words,
we want to keep the lambda pure - as functions with no side effects.

Hope this answer your question.

We can use it for just about anything. Imperative and functional are two different styles of programming the same things. With functional style, and the set of nice libraries, we can start to decompose the problem into a series of function composition and transformations. When we mix this with concepts and functions like lazy evaluation, pure functions, and parallel streams, we can implement a certain set of concurrency solutions, for example, a lot more effectively than we do with imperative style and shared mutability.