Stream API practice questions

Worked examples for Stream API

1. Question 1

   Stream.iterate is called with three arguments. What does this program print?

   import java.util.stream.*;
   
   public class Main {
       public static void main(String[] args) {
           String s = Stream.iterate(1, i -> i < 20, i -> i * 3)
                   .map(String::valueOf)
                   .collect(Collectors.joining("-"));
           System.out.println(s);
       }
   }

   1. A. 3-9

      Wrong: this assumes the seed is not part of the stream, as if next were applied once before the first emission. The seed is always the first candidate element, so 1 is emitted.

   2. B. 1-3-9Correct answer

      Correct: the three-argument iterate tests the predicate before each emission including the seed, so 1, 3, 9 pass i < 20 and 27 fails; joined with dashes they give 1-3-9.

   3. C. The program never terminates because Stream.iterate produces an infinite stream

      Wrong: this describes the two-argument iterate(seed, next), which is infinite and needs a short-circuiting op. The three-argument overload is bounded by its predicate and is finite.

   4. D. 1-3-9-27

      Wrong: this treats the predicate as a do-while condition - emit first, test afterwards - so 27 slips out before the check fails. The predicate is a hasNext, checked before emission.

   Explanation

   Trace: the three-argument Stream.iterate(seed, hasNext, next) is the stream analogue of a for loop — the predicate is tested before each element is emitted, including the seed. So it tests 1 (< 20, emit), applies next to get 3 (< 20, emit), then 9 (< 20, emit), then 27, which fails i < 20, so the stream ends without emitting it. Three elements survive, map stringifies them and joining("-") glues them with a single dash between neighbours: 1-3-9.

   Why the others are wrong: 1-3-9-27 treats the predicate as a do-while condition — emit first, test afterwards — so 27 slips out before the check fails. The predicate is a hasNext, checked before emission. 3-9 assumes the seed is not part of the stream, as if next were applied once before the first emission. The seed is always the first candidate element. The program never terminates because Stream.iterate produces an infinite stream describes the two-argument iterate(seed, next), which is indeed infinite and needs a short-circuiting op such as limit. The three-argument overload (Java 9) is bounded by its predicate and is a finite stream.

   Exam tip: Stream.iterate(1, i -> i < 20, i -> i * 3) maps one-to-one onto for (int i = 1; i < 20; i *= 3) — seed, condition, update, condition checked first. Reverse trap: with only two arguments the stream is infinite, and a terminal op like collect or count on it hangs forever.

2. Question 2

   A list of lists is flattened and each element is doubled. What does this program print?

   import java.util.*;
   
   public class Main {
       public static void main(String[] args) {
           List<List<Integer>> nested = List.of(List.of(1, 2), List.of(), List.of(3, 4, 5));
           List<Integer> flat = nested.stream()
                   .flatMap(List::stream)
                   .map(n -> n * 2)
                   .toList();
           System.out.println(flat);
       }
   }

   1. A. The code does not compile because List::stream cannot be passed to flatMap

      Assumes flatMap needs a factory like Stream::of; its parameter is a Function returning a Stream, and List::stream is exactly such a function, so it compiles.

   2. B. [[2, 4], [], [6, 8, 10]]

      This is what map(list -> ...) gives, assuming flatMap preserves nesting; flatMap flattens a stream of streams into a stream of elements.

   3. C. [2, 4]

      Assumes the empty List.of() terminates flattening; an empty inner stream simply contributes zero elements and traversal continues.

   4. D. [2, 4, 6, 8, 10]Correct answer

      flatMap splices the contents of each inner stream into one flat stream (1..5, the empty list adding nothing), then map doubles each, giving [2, 4, 6, 8, 10].

   Explanation

   Trace: flatMap maps each element to a stream and then splices the contents of that stream into the pipeline, so the three inner streams (1, 2), (nothing) and (3, 4, 5) are concatenated into a single flat stream of 1, 2, 3, 4, 5. The empty inner list simply contributes zero elements — it is not a terminator. map(n -> n * 2) then doubles each of the five values and toList() collects them in encounter order, so List.toString prints [2, 4, 6, 8, 10].

   Why the others are wrong: [[2, 4], [], [6, 8, 10]] is what map(list -> ...) would give — it assumes flatMap preserves the nesting and merely transforms each inner list. Flattening is the whole point of flatMap; a stream of streams comes back as a stream of elements. [2, 4] assumes the empty List.of() ends the flattening, as if an empty inner stream short-circuits the outer one. An inner stream that yields no elements is skipped and traversal continues with the next element. The code does not compile because List::stream cannot be passed to flatMap encodes the belief that flatMap needs a factory such as Stream::of. Its parameter is Function<? super T, ? extends Stream<? extends R>>, and List::stream is exactly such a function.

   Exam tip: map is 1-to-1, flatMap is 1-to-many (including 1-to-zero). Whenever a lambda would return a Stream, Collection or Optional and you want its contents rather than the container itself, flatMap is the operation. Reverse trap: using flatMap where the mapper returns a plain value does not compile, because a value is not a Stream.

3. Question 3

   What is the output?

   import java.util.*;
   import java.util.stream.*;
   public class Main {
       public static void main(String[] args) {
           Optional<Integer> r = Stream.of(1,2,3,4)
               .filter(n -> n % 2 == 0)
               .reduce((a,b) -> a + b);
           System.out.println(r.get());
       }
   }

   1. A. 10

      This is the sum of all four elements; the filter removed the odd values before the reduction, so they must not be included.

   2. B. 2

      Assumes the reduction returns only the first surviving element, but reduce accumulates every element rather than picking one.

   3. C. 4

      This is merely the last surviving element; reduce combines the elements, it does not select a single one.

   4. D. 6Correct answer

      Correct: the survivors 2 and 4 are combined left to right by the accumulator to give 6, wrapped in an Optional that get() then unwraps.

   Explanation

   The filter keeps only the even values, and the single-argument reduce with no identity folds those survivors together left to right, producing their combined sum wrapped in an Optional because the stream could have been empty. Unwrapping the Optional prints that total. The one-argument reduce returns Optional precisely because it has no seed value to fall back on.

4. Question 4

   Which two statements about the collectors in java.util.stream.Collectors are correct? (Choose two.)

   1. A. In groupingBy(String::length, Collectors.counting()) the value type of the resulting map is LongCorrect answer

      Collectors.counting() is declared Collector<T,?,Long>, so using it as the downstream of groupingBy produces a Map whose value type is Long.

   2. B. Collectors.partitioningBy returns a map containing both the false and true keys even when one partition matches no elementsCorrect answer

      partitioningBy always splits into exactly two buckets, so both the false and true keys are present even when one partition is empty (its value being an empty list, not a missing key).

   3. C. Collectors.groupingBy(classifier) returns a map whose keys are iterated in ascending natural order

      Confuses grouping with sorting; groupingBy returns an unordered HashMap with no ordering guarantee, so keys are not iterated in ascending natural order (a TreeMap factory is needed for that).

   4. D. The List returned by Collectors.toList() is unmodifiable, so calling add on it throws UnsupportedOperationException

      Swaps the two toLists; Collectors.toList() returns a mutable ArrayList that accepts add, whereas it is Stream.toList() that returns an unmodifiable list throwing UnsupportedOperationException.

   Explanation

   In groupingBy(String::length, Collectors.counting()) the value type of the resulting map is Long is correct: Collectors.counting() is declared as Collector<T, ?, Long>, so a groupingBy that uses it as its downstream produces a Map<K, Long>. Grouping "a", "bb", "cc" by length and reading the bucket for key 2 yields a value whose runtime class is java.lang.Long (value 2) — a common trip-up when the map is declared as Map<Integer, Integer>, which does not compile.

   Collectors.partitioningBy returns a map containing both the false and true keys ... is correct: partitioning is defined to split into exactly two buckets, and both are always present. Partitioning 1, 3, 5 on n % 2 == 0 gives {false=[1, 3, 5], true=[]} — a map of size 2 whose true entry is an empty list, not a missing key. That is precisely why partitioningBy is safe to get(true) on without a null check, while groupingBy is not.

   Why the others are wrong: Collectors.groupingBy(classifier) returns a map whose keys are iterated in ascending natural order confuses grouping with sorting. The Javadoc states there are no guarantees on the type, mutability, serializability or thread-safety of the returned map; in practice it is a HashMap. Grouping "zebra", "apple", "mango" by first character iterates its keys as [a, z, m] — not ascending. Pass a map factory such as TreeMap::new (the three-argument groupingBy) if you need sorted keys. The List returned by Collectors.toList() is unmodifiable ... swaps the two "toList"s. Collectors.toList() gives back a mutable java.util.ArrayList, and add on it succeeds. It is Stream.toList() (added in Java 16) that returns an unmodifiable list and throws UnsupportedOperationException on add. Note the Javadoc guarantees no more than that for Collectors.toList() — do not rely on mutability either; use Collectors.toCollection(ArrayList::new) when you need it.

   Exam tip: know the shape of each collector's result — counting() is Long, summingInt is Integer, averagingInt is Double, partitioningBy always has both boolean keys, and groupingBy gives an unordered map. Reverse trap: Stream.toList() and Collectors.toList() look interchangeable but differ in mutability.

5. Question 5

   Words are collected into a map of word to length. What does this program print?

   import java.util.*;
   import java.util.stream.*;
   
   public class Main {
       public static void main(String[] args) {
           Map<String, Integer> lengths = Stream.of("kiwi", "fig", "banana")
                   .collect(Collectors.toMap(s -> s, String::length, (a, b) -> a, TreeMap::new));
           System.out.println(lengths);
       }
   }

   1. A. {banana=6, fig=3, kiwi=4}Correct answer

      Correct: the TreeMap::new supplier makes the four-argument toMap build a TreeMap, so entries iterate in ascending natural (alphabetical) key order regardless of the stream's encounter order.

   2. B. {fig=3, kiwi=4, banana=6}

      Wrong: this sorts by the value (3, 4, 6) rather than by the key. A TreeMap orders by key; sorting on values would need an explicit comparator over the entries.

   3. C. {kiwi=4, fig=3, banana=6}

      Wrong: this assumes the map preserves stream encounter order, ignoring the TreeMap::new supplier. Only a LinkedHashMap supplier would give encounter order.

   4. D. The code does not compile because toMap does not accept a map supplier

      Wrong: this encodes the belief that toMap has only two- and three-argument forms. There is a four-argument overload whose last parameter is a Supplier for the result map, which is exactly what TreeMap::new supplies here.

   Explanation

   Trace: the four-argument toMap takes a key mapper, a value mapper, a merge function and a map supplier. Each word becomes a key, its length becomes the value, and the supplier TreeMap::new decides the container — so the entries live in a TreeMap and iterate in ascending natural (alphabetical) key order regardless of the stream's encounter order. TreeMap.toString therefore prints {banana=6, fig=3, kiwi=4}. The merge function (a, b) -> a is never called here because the three words are distinct keys.

   Why the others are wrong: {kiwi=4, fig=3, banana=6} assumes the map preserves stream encounter order, ignoring the TreeMap::new supplier. Only a LinkedHashMap supplier would give that. {fig=3, kiwi=4, banana=6} sorts by the value (3, 4, 6) rather than the key. A TreeMap orders by key; sorting on values needs an explicit comparator over the entries. The code does not compile because toMap does not accept a map supplier encodes the belief that toMap only has two- and three-argument forms. There is a four-argument overload whose last parameter is a Supplier<M> for the result map — that is the only way to choose the map type.

   Exam tip: a toMap or groupingBy result is a HashMap with no order guarantee unless you supply a map factory. TreeMap::new gives sorted keys, LinkedHashMap::new gives encounter order. Reverse trap: the merge function is not optional decoration — drop it from a stream with duplicate keys and toMap throws IllegalStateException.

6. Question 6

   What is printed (map toString order aside, focus on the values)?

   import java.util.*;
   import java.util.stream.*;
   public class Main {
       public static void main(String[] args) {
           Map<Integer,Long> m = Stream.of("a","bb","cc","ddd")
               .collect(Collectors.groupingBy(String::length, Collectors.counting()));
           System.out.println(m.get(2));
       }
   }

   1. A. 2Correct answer

      Correct: grouping by length with a counting downstream gives {1=1, 2=2, 3=1}, and the length-two group contains "bb" and "cc", so its count is 2.

   2. B. 1

      This is the count for the length-one or length-three groups; two strings share length two, so its count is not one.

   3. C. 3

      No length occurs three times in this data, so a count of three matches nothing here.

   4. D. [bb, cc]

      This would be the value only if the default toList() downstream were used; counting() replaces the list with a Long count.

   Explanation

   A downstream counting collector makes groupingBy map each distinct key to the number of elements in that group rather than to a list, so the value type becomes Long. Two of the strings share length two, so the count stored under that key is two. The downstream collector replaces the default toList(), which is why the value is a count and not a list of strings.

7. Question 7

   What is the output?

   import java.util.stream.*;
   public class Main {
       public static void main(String[] args) {
           int sum = IntStream.rangeClosed(1, 5).sum();
           System.out.println(sum);
       }
   }

   1. A. 10

      This is what range(1, 5) would give: the half-open form excludes the upper bound, summing only 1+2+3+4.

   2. B. 14

      Matches no variant of the range; it would require dropping the 1 from the closed range.

   3. C. 20

      Corresponds to no range here, such as 2..6; both bounds are exactly as written.

   4. D. 15Correct answer

      Correct: rangeClosed(1, 5) is inclusive of 5, so 1+2+3+4+5 = 15.

   Explanation

   rangeClosed includes its upper bound, so it produces one through five, and summing them gives fifteen. The half-open range form would exclude the upper bound and produce a smaller total. The exam hides this off-by-one inside a sum so that a wrong bound lands on one of the distractors.

8. Question 8

   The three-argument groupingBy below totals order quantities per category. What does this program print?

   import java.util.*;
   import java.util.stream.*;
   
   public class Main {
       record Item(String cat, int qty) {}
   
       public static void main(String[] args) {
           List<Item> items = List.of(
                   new Item("fruit", 3), new Item("veg", 5), new Item("fruit", 4),
                   new Item("dairy", 2), new Item("veg", 1));
           Map<String, Integer> totals = items.stream()
                   .collect(Collectors.groupingBy(Item::cat, TreeMap::new,
                           Collectors.summingInt(Item::qty)));
           System.out.println(totals);
       }
   }

   1. A. {fruit=7, veg=6, dairy=2}

      Has the right totals but encounter-order keys, which is what an insertion-ordered map factory would give; the supplied sorted-map factory orders keys alphabetically.

   2. B. {dairy=1, fruit=2, veg=2}

      Counts the items per group instead of summing their quantities, which is counting rather than summing behaviour.

   3. C. {dairy=2, fruit=4, veg=1}

      Keeps only the last item's quantity per key (a map-merge behaviour); the summing collector adds the quantities of all items in each group.

   4. D. {dairy=2, fruit=7, veg=6}Correct answer

      Correct — the sorted-map factory orders keys alphabetically (dairy, fruit, veg) and the summing collector totals each group's quantities (fruit 3+4=7, veg 5+1=6, dairy 2).

   Explanation

   The three-argument grouping collector builds its result with the supplied map factory, and a sorted-map factory arranges the keys in natural (alphabetical) order rather than encounter order. Its downstream summing collector adds up each group's integer quantities, as opposed to merely counting the elements or keeping only the last one per key.