Working with Streams and Lambda Expressions practice questions

Step 1: Make constructor private; Step 2: Declare private static volatile instance variable; Step 3: Provide public static getInstance() method; Step 4: Inside getInstance, perform first null check, synchronize on class, second null check, then instantiate.

Why wrong: This order is incorrect because the instance variable must be declared before the getInstance method uses it, but placing the constructor before the variable is valid. However, the correct order typically declares the variable first to emphasize its static nature. More importantly, the sequence of steps is not strictly wrong but optimal ordering is variable first.

Step 1: Declare private static volatile instance variable; Step 2: Provide public static getInstance() method; Step 3: Make constructor private; Step 4: Inside getInstance, perform first null check, synchronize on class, second null check, then instantiate.

Why wrong: This order is incorrect because the constructor should be made private before defining the getInstance method that relies on it. If the constructor is not private, external code could create instances, breaking the singleton pattern.

Step 1: Declare private static volatile instance variable; Step 2: Make constructor private; Step 3: Inside getInstance, perform first null check, synchronize on class, second null check, then instantiate; Step 4: Provide public static getInstance() method.

Why wrong: This order is incorrect because the getInstance method must be defined before its implementation logic. The method declaration (Step 4) should come before the body (Step 3).

Collectors.toMap(Function.identity(), e -> 1L, Long::sum)

Why wrong: This uses toMap with identity and a merge function, but it is not a grouping operation; it would fail on duplicate keys without proper merge, and it does not produce a grouped count map.

Collectors.groupingBy(Function.identity(), Collectors.count())

Why wrong: Collectors.count() does not exist; the correct method is Collectors.counting(). This causes a compilation error.

transactions.stream().mapToDouble(Transaction::amount).filter(t -> t.type().equals("SALE")).sum()

Why wrong: mapToDouble returns DoubleStream, which does not have type method; filter cannot be applied after mapToDouble in this way.

transactions.stream().filter(t -> t.type().equals("SALE")).filter(t -> t.currency().equals("USD")).mapToDouble(Transaction::amount).sum()

Why wrong: Filters by type then currency, but currency filter is not needed if only SALE transactions are considered; also missing currency check for USD.

transactions.stream().map(Transaction::amount).reduce(0.0, (a, b) -> a + b)

Why wrong: Missing filter for type and currency; also reduce works but sum() is more concise.

a

Why wrong: The identity is not ignored; all elements are combined.

Optional[abc]

Why wrong: reduce with identity returns a value, not Optional.

cba

Why wrong: Order is preserved as sequential stream.

Collectors.toMap(Function.identity(), i -> Arrays.asList(i, i * i), (v1, v2) -> v1)

Why wrong: Works only if keys are unique; merge function is redundant but still produces Map<Integer, List<Integer>>. However, it's not the best practice; also fails if duplicates exist.

Collectors.groupingBy(Function.identity(), Collectors.mapping(i -> i * i, Collectors.toList()))

Why wrong: Groups by the integer, but values are lists of squares only, not including the original number.

Collectors.toMap(Function.identity(), i -> i * i)

Why wrong: Produces Map<Integer, Integer>, not Map<Integer, List<Integer>>.

Optional[6]

Why wrong: Println would print Optional[6] only if opt is printed directly, but opt.get() returns Integer.

Optional.empty

Why wrong: Stream is non-empty.

NoSuchElementException

Why wrong: Stream has elements.

Parallel streams always improve performance.

Why wrong: Not always; depends on context.

Streams are always finite.

Why wrong: Infinite streams exist.

Intermediate operations are executed eagerly.

Why wrong: They are lazy.

[apple, banana, cherry]

Why wrong: That would be a list, not a map.

{5=[5], 6=[6, 6]}

Why wrong: Values are words, not lengths.

{apple=[5], banana=[6], cherry=[6]}

Why wrong: Map keys are lengths, not words.

stream().sorted(Comparator.comparingInt(String::length).reversed()).findFirst()

Why wrong: Works but not as direct as max.

stream().min(Comparator.comparingInt(String::length))

Why wrong: Returns shortest.

stream().sorted(Comparator.comparingInt(String::length)).findFirst()

Why wrong: Returns shortest.

No output

Why wrong: There are even numbers.

12345

Why wrong: No filter applied.

135

Why wrong: Filter for odd numbers.

a, b -> a + b

Why wrong: Invalid: multiple parameters require parentheses.

(a, b) -> { a + b; }

Why wrong: Invalid: block body needs a return statement, or must be a void-compatible block; a + b; is an expression statement, not a return.

(int a, b) -> a + b

Why wrong: Invalid: mixed explicit and inferred types.

A stream can be traversed multiple times.

Why wrong: This statement is false. A stream can only be traversed once. Attempting to traverse it a second time throws an IllegalStateException.

The collect() method is an intermediate operation.

Why wrong: This statement is false. collect() is a terminal operation; it consumes the stream and produces a result.

The map() method returns a stream of the same type.

Why wrong: This statement is false. map() applies a function to each element and can change the element type; the resulting stream type is determined by the function's return type.

A lambda expression can throw any checked exception.

Why wrong: False: Lambdas can only throw checked exceptions declared in the functional interface method, not any checked exception.

A lambda expression can be used to implement multiple abstract methods.

Why wrong: False: A lambda can only implement one abstract method, not multiple.

A lambda expression can be used to create an instance of an abstract class.

Why wrong: False: Lambdas cannot create instances of abstract classes; they work only with functional interfaces.

trades().filter(t -> t.quantity() > 0 && t.price() > 0).collect(Collectors.toMap(Trade::symbol, t -> t.quantity() * t.price(), Double::sum))

Why wrong: Works but toMap is not intended for grouping; groupingBy is more semantic.

trades().filter(t -> t.quantity() > 0 && t.price() > 0).collect(Collectors.toMap(Trade::symbol, t -> t.quantity() * t.price(), (v1, v2) -> v1 + v2))

Why wrong: Works but groupingBy is better for grouping operations.

trades().filter(t -> t.quantity() > 0 && t.price() > 0).reduce(new HashMap<>(), (map, t) -> { map.merge(t.symbol(), t.quantity() * t.price(), Double::sum); return map; }, (m1, m2) -> { m1.putAll(m2); return m1; })

Why wrong: Reduce with mutable accumulation is not recommended; combiner is incorrect (overwrites instead of merging).

logs.parallelStream().filter(l -> l.timestamp() > System.currentTimeMillis() - 3600000).collect(Collectors.groupingBy(LogRecord::userId, Collectors.counting())).entrySet().stream().sorted(Map.Entry.comparingByKey()).limit(3).collect(Collectors.toList())

Why wrong: Sorted by userId, not count.

logs.parallelStream().collect(Collectors.groupingBy(LogRecord::userId, Collectors.counting())).entrySet().stream().sorted(Map.Entry.comparingByValue().reversed()).limit(3).collect(Collectors.toList())

Why wrong: No time filter.

logs.parallelStream().filter(l -> l.timestamp() > System.currentTimeMillis() - 3600000).collect(Collectors.groupingBy(LogRecord::action, Collectors.counting())).entrySet().stream().sorted(Map.Entry.comparingByValue().reversed()).limit(3).collect(Collectors.toList())

Why wrong: Grouped by action, not userId.

orders.stream().filter(o -> o.getStatus() != "SHIPPED").map(Order::getId).collect(Collectors.toList())

Why wrong: Filters out SHIPPED orders instead of keeping them.

orders.stream().map(Order::getId).filter(id -> id.equals("SHIPPED")).collect(Collectors.toList())

Why wrong: Filters IDs, but IDs are not status strings.

orders.stream().filter(Order::getStatus).map(o -> o.getId()).collect(Collectors.toList())

Why wrong: filter expects a Predicate<Order>, but getStatus returns String, not boolean.

Parallel streams always improve performance over sequential streams.

Why wrong: Performance depends on data size and operation complexity.

Any lambda expression is safe to use in a parallel stream.

Why wrong: Lambdas must be stateless and non-interfering.

Using parallel streams guarantees the order of elements in the result.

Why wrong: Order is not guaranteed unless using forEachOrdered.

books.stream() .filter(b -> b.getPrice() > 20) .collect(Collectors.groupingBy(Book::getGenre, Collectors.summingDouble(Book::getPrice)));

Why wrong: Incorrect. It filters individual books with price >20 before grouping, so it only considers books with price above $20, not all books in the genre. The average should be computed on all books in the genre, not just those above $20. This would incorrectly exclude genres where many books are below $20 but the average still exceeds $20.

books.stream() .collect(Collectors.groupingBy(Book::getGenre, Collectors.averagingDouble(Book::getPrice))) .entrySet().stream() .filter(e -> e.getValue() > 20) .collect(Collectors.toMap(Map.Entry::getKey, e -> { return books.stream().filter(b -> b.getGenre().equals(e.getKey())).mapToDouble(Book::getPrice).sum(); }));

Why wrong: Incorrect. Although it groups by genre and computes the average correctly, it then re-filters the original stream to compute the sum for each qualifying genre. While this may produce the correct result, it is inefficient and not an idiomatic use of streams. More importantly, the approach is error-prone if the source list is modified or if parallelism is used, and it does not follow the concise intent of the task.

books.stream() .collect(Collectors.groupingBy(Book::getGenre, Collectors.summingDouble(Book::getPrice))) .entrySet().stream() .filter(e -> e.getValue() > 20) .collect(Collectors.toMap(Map.Entry::getKey, Map.Entry::getValue));

Why wrong: Incorrect. It groups by genre and computes the sum directly, then filters based on the sum being greater than 20. However, the requirement is to filter based on the average price being greater than $20, not the total sum. This would incorrectly include genres with a small number of expensive books and exclude genres with many cheap books that still have a high average.

stream.collect(Collectors.toMap(Employee::getDepartment, e -> { List<Employee> l = new ArrayList<>(); l.add(e); return l; }, (l1, l2) -> { l1.addAll(l2); l1.sort(Comparator.comparing(Employee::getSalary).reversed()); return l1.subList(0, Math.min(3, l1.size())); }))

Why wrong: toMap is intended for one-to-one mapping; merging lists is complex and error-prone, and does not guarantee correct per-department top 3.

stream.sorted(Comparator.comparing(Employee::getSalary).reversed()).collect(Collectors.groupingBy(Employee::getDepartment, Collectors.toList())).values().stream().map(l -> l.subList(0, Math.min(3, l.size()))).collect(Collectors.toList())

Why wrong: Sorting globally before grouping loses per-department top 3; the top 3 overall may all be from one department.

stream.collect(Collectors.groupingBy(Employee::getDepartment, Collectors.toList())).entrySet().stream().flatMap(e -> e.getValue().stream().sorted(Comparator.comparing(Employee::getSalary).reversed()).limit(3)).collect(Collectors.toList())

Why wrong: This collects all employees into a Map then flattens, but flatMap is unnecessary and order may not be maintained properly.

A stream can be consumed by multiple terminal operations sequentially.

Why wrong: A stream can have at most one terminal operation; after that, the stream is consumed and cannot be used again.

Intermediate operations on a stream are executed eagerly.

Why wrong: Intermediate operations are lazy; they are not executed until a terminal operation is invoked.

Lambda expressions introduce a new level of scope, similar to an anonymous inner class.

Why wrong: Lambda expressions do not introduce a new scope; they share the scope with the enclosing method, so variables from the outer scope are accessible directly.