Multi statement lambda and for each anti patterns

When I do a code review of lambda/stream code, I am immediately suspicious of two things – block statement lambdas and forEach().

What’s wrong with this? It’s functional programming right?

List<Integer> list = Arrays.asList(1,2,3,4,5,6,7,8,9,10);
		
AtomicInteger sum = new AtomicInteger();
List<Integer> odds = new ArrayList<>();
List<Integer> evens = new ArrayList<>();
		
list.forEach(n -> {
	sum.addAndGet(n);
	if (n % 2 == 0) {
		evens.add(n);
	} else {
		odds.add(n);
	}
});
		
odds.forEach(System.out::println);
System.out.println();
evens.forEach(System.out::println);
System.out.println();
System.out.println(sum);

Well? Not really. It does have a lambda. It doesn’t have a stream, but that’s easy enough to fix: list.stream().forEach(…).

All better? No. Just because you are using a stream doesn’t mean you are doing functional programming. I would much rather see this code as:

List<Integer> list = Arrays.asList(1,2,3,4,5,6,7,8,9,10);
		
		
list.stream()
   .filter(x -> x % 2 == 1)
   .forEach(System.out::println);

System.out.println();

list.stream()
   .filter(x -> x % 2 == 0)
   .forEach(System.out::println);

System.out.println();

list.stream()
   .mapToInt(x -> x)
   .sum();

Yes, I’m still using forEach(). But now I’m using it for one purpose (printing) rather than sticking logic in it.

Whenever I see a forEach() or lambda with more than one statement, my first thought is “could this be clearer or more functional.” Often the answer is yes. Filter(), map() and collect() are you friends.

And if I did need that List?

list.stream()
   .filter(x -> x % 2 == 1)
   .collect(Collectors.toList());

[2019 oracle code one] Lambda, Streams and Collectors Lab

Lambda, Streams and Collectors Lab

Speakers: Stuart Marks, Maurice Naftalin, Jose Paumard & Gustavo Durand

For more blog posts, seeĀ The Oracle Code One table of contents


The lab is self paced

https://github.com/JosePaumard/code-one-2019-lambda-stream-collector-lab

I like that it is organized by topic so you can pick what you want to learn. Since “someone” believed I didn’t need to be here, I decided to blog about what I did and learned.

  • O_SimpleCollectors
    • I forgot Comparator.naturalOrder() exists because I hardly use it.
    • I forgot you can’t use Function.identity() with primitives and instead have to write a lambda: ex: x -> x.
  • P_HarderCollectors
    • I almost never use flatMap. I didn’t think to use it combined with splitAsStream to read words from a file. I do a lot of file processing though so this is definitely an idiom I need to remember! I shall type it in for each exercise in this lab that uses it (vs copy/paste) in order to ingrain it in my fingers! reader.lines().flatMap(SPLIT_PATTERN::splitAsStream) [edit: I think I’ve typed this enough times to remember it forever!]
    • The extra challenge to write a groupingBy using toMap. I knew I needed to use a merge function, but the types didn’t match my expectations. I learned that:
      • if you write a value instead of a lambda for the value function, you get a compiler error on the merge function (about the + operator being invalid ) and not the value function for not being a lambda
      • if you write a value function that returns an int instead of a long, you get a compiler error on the merge function and not the value function (because the merge function result is what gets set to the return value)
    • If you try to read from a reader that has already called reader.lines(), you don’t get any lines. Doh!
    • flatMap(String::chars) doesn’t work because chars() returns an IntStream. flatMapToInt(String::chars) does work
    • Entry has comparingByKey() and comparingByValue() methods
    • Remember to use groupingBy when aggregating and toMap when one to one
    • Need to call boxed() on an IntStream to be able to use partitioning by. An IntStream doesn’t have a collect method that takes a Collector as a parameter
    • Partitioning by can take a nested collector (ex: summing int)
  • L_HarderStreams
    • Convert type using mapToInt() before calling max
    • Forgot about Comparator.comparing() – I knew about this one earlier today! I think I’m getting tired :). I’m a morning person. Coding at 6:30pm is less than ideal for me.
    • Character.toString(Int) exists in Java 11. This means you can call mapToInt(String::chars).mapToObj(Character::toString)
    • The concept of using IntStream for an index and referring to a separate list (I would use a for loop for this since I need the index, but it’s a good tool to have in the toolbox)

My take

The lab is great. I like that it can be as easy or as hard as you want. I like they support multiple versions of Java and multiple IDEs. I completed the hard stream and collectors hard exercises

The room is terrible. It’s not really a room. It’s a grid of pipe/drape separated areas. I can hear every word in the room next to us. It got better. Once I got into the lab I was able to tune out the surroundings.

Also, my back hurts. Live blogging was fine. Different angle and I hardly look at the laptop. Coding for two hours (and I did take a break and stretch) was an awkward neck/back angle. How do people code on a laptop full time?

JavaOne – Streams in JDK 8

“Streams in Java 8 – The good, the bad & the ugly”

Speaker: Simon Ritter & Stuart Marks
[Simon has the Twtter handle @speakjava; very cool]

For more blog posts from JavaOne, see the table of contents


Need to think differently. We are used to imperative programming with loops and variables.

Dealing wih exceptions
ugly code – three lines of code and hard to tell what it does

Problems:

  • looks like Perl
  • returns null (vs Optional or empty string)
  • split is called twice so wasted work
  • skipped URLDecoder.decode() because didn’t want to deal with a checked exception – but lost functionality. Problem caused by a missing API in Java so have to use decode.

Better approach:

  • use a method with a try/catch block; call that method from the stream
  • use Map.entry to simulate a tuple
  • Use single char (vs regex) in split. If only pass one character to split, far faster
  • split() is overloaded to take a numeric limit to how many are returned

Imperative streams
inside the for each is a print, and if statement and a LongAdder variable (good for frequent writes and infrequent reads)

then refactored to use mapToInt, a println and an if statement and a local variable. more complicated and still not functional

then switched to peek and no variabe but still an if statement (well a ternary)

finally switched to use a filter and count instead of sum

still not 100% functional because println is a side effect. ok for debugging

[good showing evolution to get functional]

Problems

  • Easy to misuse forEach() because feels familiar. But easily leads to side effects
  • Imperative thinking “for each of these I want to..”
  • Pause to consider if should use for each

Mixing internal and external iteration
for loop running 12 times and then getting data for each month with filter checking Month.of(x) – doesn’t work because x isn’t effectively final

“solve” effectively final by setting to different interim variable

IntStream.range(0,12).forEach – uses internal iteration but forEach. Marginaly better as don’t need interim variable

Instead return a nested map of Month to Map with nested grouping by so only need one iteration – the data stream

Problems

  • Going through data.stream() 12 times
  • forEach cheat
  • array not right data structure; it’s really a map of month to value

Hands on lab question
reduce (“”, (a,b) -> a+b) – works but inefficient because String concatenation

reduce(a,b) -> sb.append(b) – fails because ignores the first letter.

next attempt uses an if statement in reduce

then tried a custom collector. works but more complicated than necessary
Collector.of(StringBuilder::new, StringBuilder::append, StringBuilder::append, StringBuilder::toString

or just use Collectors.joining()

Problems

  • If not using a parameter, it is probably wrong
  • Side effects
  • if stateent version not associative so would fail when run in parallel

Misc

  • can’t use same stream multiple times
  • method references are slightly more efficient than lambdas because lambda gets added into a method in bytecode. Saves a level of indirection by using method reference. But only slightly
  • Calling .sorted() multiple times vs chaining comparing.thenComparing – the later is better [also works because preserves sort :)]
  • parallel streams do more work. might or might not complete faster. uses fork-join pool. number of threads defaults to number of CPUs. In Java9, this is # CPUs for container. On Jaa 8, it was for physical machine
  • Nested parallel streams is bad idea because using same threads so performance is worse. Can create ForkJoinPool if must. Buyer beware; this is an implementation specific behavior and tied to the profile of the machine you write it for.

My take: Fun start to he morning. I like that they covered common things in an entertaining way and not common things. Something to learn for everyone!