Lambdas and Streams

Method references provide a more concise alternative to lambdas when referencing existing methods:

Differences:

• Method references are typically shorter and clearer for simple method calls
• Lambdas excel when computation logic doesn't match an existing method
• Lambdas can provide descriptive parameter names as documentation
• Method references can't access or manipulate parameters beyond passing them to the method

When to prefer method references:

• When referencing a method that exactly matches the functional interface
• When the method name clearly describes the operation
• When brevity improves readability

  // Method reference: clean and concise
  words.sort(comparingInt(String::length));
  
  // Lambda: more verbose for this case
  words.sort((s1, s2) -> Integer.compare(s1.length(), s2.length()));

When to prefer lambdas:

• When parameter names provide useful documentation
• When minor computation is needed beyond a method call
• When the method is in the same class and has a very long name

  // Lambda preferred here (method name is excessive)
  service.execute(() -> action());
  // vs less readable reference
  service.execute(GoshThisClassNameIsHumongous::action);

Rule of thumb: Where method references are shorter and clearer, use them; where they aren't, stick with lambdas.

Prefer traditional iteration over streams when:

1. You need access to or modification of local variables within the loop
2. You need to return from the enclosing method, break/continue loops, or throw checked exceptions
3. You need simultaneous access to corresponding elements from multiple data sources
4. The operations don't map cleanly to stream operations (transform, filter, combine, accumulate, or search)
5. You're working with char values (due to Java's limited support for char streams)
6. The code would become less readable or more complex when expressed as streams
7. Debugging requirements favor the clarity of step-by-step iteration
8. You need precise control over iteration order or conditional processing

Key principle: Use streams when they make code clearer; don't force-fit them where traditional iteration is more expressive.

Lambdas have significant limitations for complex logic and should be used judiciously:

Limitations:

1. Limited documentation capacity

   • No Javadoc
   • Only parameter names provide context
   • Unclear intent for complex operations

2. Readability degradation with complexity

   • Multi-line lambdas become hard to parse visually
   • Nested operations create "arrow code" (excessive indentation)

3. Debugging challenges

   • Difficult to set breakpoints
   • Stack traces can be confusing
   • Anonymous nature makes identifying specific lambdas difficult

4. Testing difficulties

   • Not directly testable in isolation
   • Must test through the consuming method

Best practices:

1. Keep lambdas concise

   • Ideal: One line
   • Maximum: Three lines
   • Refactor longer operations into named methods

2. Extract complex logic to named methods

   // BAD: Complex logic in lambda
   stream.filter(customer -> {
       if (customer.getAge() > 18 && customer.hasActiveAccount()) {
           return customer.getPurchases() > 10 || customer.getBalance() > 1000;
       }
       return false;
   });
   
   // GOOD: Logic extracted to named method
   stream.filter(this::isValuableCustomer);
   
   // The named method is clear and testable
   private boolean isValuableCustomer(Customer customer) {
       if (customer.getAge() <= 18 || !customer.hasActiveAccount()) {
           return false;
       }
       return customer.getPurchases() > 10 || customer.getBalance() > 1000;
   }

3. Make parameter names descriptive

   • Avoid single-letter parameters except in trivial cases
   • Use meaningful names for business logic

4. Prefer method references for simple method calls

   • list.forEach(System.out::println) over list.forEach(x -> System.out.println(x))

5. Add comments for non-obvious lambdas

   // Identifies customers eligible for premium upgrade
   customers.filter(c -> c.getSpending() > threshold && c.getLoyaltyYears() > 5)

Remember: If a lambda is hard to understand at a glance, it should be refactored into a named method.

This creates potential ambiguity for client code that may require explicit casts to indicate the correct overloading.

Example: The submit method of ExecutorService can take either a Callable<T> or a Runnable, which can create ambiguous method calls requiring casts.

Best practice: Do not write overloadings that take different functional interfaces in the same argument position. This is a special case of the advice to "use overloading judiciously."

Challenge: Once you map a value to another value in a stream, the original value is lost.

Workarounds:

1. Map to a pair object:

   • Create a container holding both original and new values
   • Drawbacks: Messy, verbose code that defeats a primary purpose of streams
   • Especially problematic if needed across multiple pipeline stages

2. Invert the mapping (preferred when applicable):

   • When possible, compute the earlier-stage value from the later-stage value
   • Example: With Mersenne primes (2ᵖ-1), you can recover the exponent p from the Mersenne number by calculating the bit length

Choose approach based on the specific requirements and complexity of your pipeline.

Boolean operations are supported through:

1. Direct boolean supplier:

   • BooleanSupplier - the only interface with explicit mention of boolean in its name

2. Predicate variants (all return boolean values):

   • Predicate<T> - tests an object
   • BiPredicate<T,U> - tests two objects
   • IntPredicate - tests an int value
   • LongPredicate - tests a long value
   • DoublePredicate - tests a double value

Unique characteristic: Despite boolean being a primitive type, there's no comprehensive set of boolean-specific functional interfaces. Instead, boolean return values are primarily handled through the Predicate family, with BooleanSupplier being the only exception with direct boolean naming.

The key principle of the streams paradigm is to structure computations as a sequence of transformations where each stage is as close as possible to a pure function of the previous stage.

A pure function:

• Depends only on its input
• Does not depend on mutable state
• Does not update any state

Functions passed to stream operations (both intermediate and terminal) should be free of side-effects to properly implement this paradigm.

Example:

// Bad: Uses side effects
Map<String, Long> freq = new HashMap<>();
words.forEach(word -> {
    freq.merge(word.toLowerCase(), 1L, Long::sum); // Mutates external state
});

// Good: Side-effect free
Map<String, Long> freq = words
    .collect(groupingBy(String::toLowerCase, counting()));

Limitations of Collection as return type:

1. Size constraints:

   • Collection.size() returns int, limiting sequence length to Integer.MAX_VALUE
   • Stream and Iterable can represent infinite sequences

2. Memory requirements:

   • Collections typically store all elements in memory
   • Streams can be lazily evaluated, processing elements on demand
   • Large datasets may cause OutOfMemoryError with collections

3. Implementation complexity:

   • Must implement contains() and size() in addition to iterator()
   • These operations may be inefficient or impossible to implement for some sequences
   • More complex to implement than a simple Stream or Iterable

4. Practical limitations:

   • For large sequences like power sets (2^n elements), collections become impractical quickly
   • Power sets become unmanageable at n>30 due to size constraints

While Collection provides both iteration and streaming capabilities, these limitations make Stream or Iterable preferable for very large or infinite sequences.

The most common anti-pattern in stream parallelization is introducing shared mutable state in stream operations.

It manifests through:

1. Operations with side effects:

// WRONG: side effect modifying external counter
AtomicLong counter = new AtomicLong();
stream.parallel().forEach(x -> counter.incrementAndGet());

2. Collecting into shared collections:

// WRONG: concurrent modifications to shared collection
List<String> results = new ArrayList<>();
stream.parallel().forEach(results::add); // Race condition!

3. Order-dependent operations:

// WRONG: order matters but gets scrambled by parallelism
String concatenated = stream.parallel()
                           .reduce("", (a, b) -> a + b);

4. Using stateful operations:

// WRONG: stateful predicate causes inconsistent filtering
Set<String> seen = new HashSet<>();
stream.parallel().filter(seen::add); // Non-deterministic!

Such code typically produces non-deterministic results, race conditions, or actually performs worse than sequential code due to synchronization overhead.

BigInteger.isProbablePrime(int certainty) works as follows:

1. It implements the Miller-Rabin primality test, a probabilistic algorithm
2. The certainty parameter (50 in the example) determines how many rounds of testing to perform
3. Higher values increase confidence but take longer
4. Returns false for definite composites, true for probable primes
5. The probability of a false positive is less than 2^(-certainty)

Suitable for parallelization because:

• CPU-intensive with no I/O waiting
• Completely independent per number (no shared state)
• Substantial work per element (especially for larger numbers)
• Fixed memory footprint (doesn't create excessive objects)
• No side effects or ordering requirements
• Computation time scales predictably with input size

These properties create an "embarrassingly parallel" problem where performance scales almost linearly with available cores.