The Operations, and What collect Really Does

Sort them by return type and the list organises itself.

Two pairs in that table are worth looking at side by side.

peek and forEach do the same thing to each element. peek is intermediate and forEach is terminal, so peek alone runs nothing at all. It exists for looking, not for doing.

sorted and min both need an order. sorted gives you back a stream and does no comparing yet. min gives you the answer and does all of it.

Three of these lean on work you did in earlier phases.

sorted() with no argument needs Comparable, from Section 10.8. Without it you get a ClassCastException at run time. sorted(Comparator) takes the order from outside instead, which is the whole point of Comparator.

distinct() asks equals, from Section 8.3. Miss the override and it does nothing, silently.

min and max return Optional, because an empty stream has no smallest element.

Now collect. The word to hold on to is recipe.

List<String> names = staff.stream().map(Emp::name).collect(Collectors.toList());

collect says: gather these up. Collectors.toList() is a recipe telling it how. Collectors is a class full of ready made recipes, and that is all it is.

Collectors.toList()          // into a List
Collectors.toSet()           // into a Set, duplicates dropped by equals
Collectors.joining(", ")     // into one String with a separator
Collectors.counting()        // how many
Collectors.averagingInt(f)   // the average of a number pulled out of each
Collectors.toMap(k, v)       // into a Map, given how to get keys and values

The one that earns its keep is groupingBy:

Map<String, List<Emp>> byDept = staff.stream()
    .collect(Collectors.groupingBy(Emp::dept));

One line. You get a Map whose keys are the departments and whose values are lists of the people in each. Writing that by hand is a loop, a HashMap, and a computeIfAbsent call, which is exactly what you wrote in Section 10.6.

And recipes nest. The second argument says what to do with each group instead of just listing them:

Map<String, Long> countPerDept = staff.stream()
    .collect(Collectors.groupingBy(Emp::dept, Collectors.counting()));
// {Sales=2, Eng=2}

That is the nesting that looked alarming a moment ago. Read it as: group by department, and for each group, count. The second recipe describes the group.

reduce squashes a stream to one value.

staff.stream().map(Emp::salary).reduce(0, Integer::sum);   // 300

Start at 0. Take the running total and the next salary, add them, keep going. Every other terminal operation that produces one value is a special case of this.

Answer from memory before opening the explanation. Then compare your rule with the answer and revisit the example if they differ.

1. How do you tell an intermediate operation from a terminal one without looking anything up?

   Show the answer

   Look at what it returns.

   An intermediate operation returns a Stream. That is what lets you keep adding dots, and it is why it cannot have done any work: it has nothing to report yet.

   A terminal operation returns anything else. A List, a number, a boolean, an Optional, or nothing at all in the case of forEach. The chain stops there because there is no stream left to add to.

   So the return type is the rule, not a category you have to remember. If you can keep typing a dot and get more stream methods, nothing has run yet.

2. `distinct()` on a list of your own objects leaves the duplicates in. Why?

   Show the answer

   Because distinct asks equals, and your class did not override it.

   Without an override, equals is the one inherited from Object, which compares references. Two objects holding identical values are different references, so both are kept. This is the same failure as Section 8.3, arriving somewhere new.

   It fails quietly. No exception, no warning, just a list that still has duplicates in it. Same for Collectors.toSet, groupingBy keys, and anything else that has to decide whether two things are the same.

   Fix the class, not the stream. Override equals and hashCode together, as the contract in Section 8.3 requires.

3. `reduce(0, Integer::sum)` gives you an `int`. `reduce(Integer::sum)` gives you an `Optional<Integer>`. Why the difference?

   Show the answer

   Because of the empty stream.

   With a starting value, an empty stream has an obvious answer: the starting value. Sum nothing and you get 0, so there is always something to return.

   Without one there is no answer at all. What is the sum of no numbers, when you were not told where to start? Not zero, because you never said zero. There is nothing honest to return, so Java returns an Optional that may be empty.

   The type is telling you about a case you might not have thought about, which is the whole argument for Optional in Section 11.5.

Write each solution in VS Code, predict its result, and then run the checks. Reading an example does not replace implementing it.

4 exercises100 pointsabout 100 minutes

import java.util.*;
import java.util.stream.*;

public class SplitThem {
    public static void main(String[] args) {
        // Put each of these in one of two columns, without looking anything up.
        // Use only this question: does it hand back a Stream, or an answer?
        //
        //   filter  map  flatMap  distinct  sorted  peek  limit  skip
        //   forEach  toList  collect  count  reduce  min  max  findFirst
        //   anyMatch  allMatch  noneMatch  toArray

        // TODO: write your two lists in a comment
        // TODO: then check each one by typing it and reading what your editor says
        // TODO: peek and forEach do the same thing. Which column is each in, and why?
        // TODO: sorted and min both need an order. Which one does the comparing?
    }
}

import java.util.*;
import java.util.stream.*;

public class StillThere {
    static class Unit {
        final String name; final int id;
        Unit(String n, int i) { name = n; id = i; }
        public String toString() { return name + "#" + id; }
        // no equals, no hashCode. On purpose.
    }

    public static void main(String[] args) {
        List<Unit> units = List.of(
            new Unit("Atlas", 101), new Unit("Atlas", 101), new Unit("Beacon", 102));

        // TODO: distinct(). Predict the size first. Then run it.
        // TODO: Collectors.toSet(). Predict, then run.
        // TODO: groupingBy(u -> u). Predict how many keys, then run.
        // TODO: now add equals and hashCode, and run all three again.
    }
}

import java.util.*;
import java.util.stream.*;

public class Grouping {
    record Emp(String name, String dept, int salary) { }

    public static void main(String[] args) {
        List<Emp> staff = List.of(
            new Emp("Aditya", "Eng",   90),
            new Emp("Rohit",  "Eng",   70),
            new Emp("Sonu",   "Sales", 60),
            new Emp("Rohan",  "Sales", 80));

        // TODO: group by department, BY HAND, with a loop and computeIfAbsent
        // TODO: the same thing with Collectors.groupingBy. Compare the two.
        // TODO: count per department, using a second collector inside the first
        // TODO: average salary per department
        // TODO: print the map. Is Eng first? Why not? Then make it first.
    }
}

import java.util.*;
import java.util.stream.*;

public class Placement {
    static int mapCalls = 0;

    static String expensive(String s) {
        mapCalls++;
        return s.toUpperCase();
    }

    public static void main(String[] args) {
        List<String> names = new ArrayList<>();
        for (int i = 0; i < 1_000_000; i++) names.add("name" + i);

        // TODO: map then limit(10). Count the map calls.
        // TODO: limit(10) then map. Count again. Same answer?
        // TODO: filter then map, and map then filter. Count both.
        // TODO: add sorted() to a chain over an endless stream. Predict what happens
        //       BEFORE you run it, and be ready to stop the program.
    }
}