Java 8+ & Functional Programming

A method reference is compact syntax for a lambda whose entire body is just calling one existing method — the compiler infers the parameter list from the target functional interface, so you don't need to spell it out.

There are four forms:

1. Static method reference — Type::staticMethod:

Function<String, Integer> parse = Integer::parseInt;
// equivalent to: s -> Integer.parseInt(s)

2. Bound instance method reference — instance::method (the receiver object is already fixed):

String prefix = "Hello, ";
Function<String, String> greet = prefix::concat;
// equivalent to: s -> prefix.concat(s)

3. Unbound instance method reference — Type::instanceMethod (no specific instance yet — the first lambda parameter becomes the receiver, remaining parameters are passed to the method):

Function<String, Integer> length = String::length;
// equivalent to: s -> s.length()

BiFunction<String, String, Boolean> startsWith = String::startsWith;
// equivalent to: (s, prefix) -> s.startsWith(prefix)

4. Constructor reference — Type::new:

Supplier<ArrayList<String>> factory = ArrayList::new;
// equivalent to: () -> new ArrayList<>()

Function<String, StringBuilder> toBuilder = StringBuilder::new;
// equivalent to: s -> new StringBuilder(s)

Method references are purely syntactic sugar over an equivalent lambda — they compile to the same kind of invokedynamic-based construct — and are generally preferred over an explicit lambda when the lambda would do nothing but forward its arguments to an existing method, since they read more directly as "call this method" rather than restating the parameter list.

Collectors provides ready-made implementations of Collector, the strategy object Stream.collect() uses to accumulate stream elements into a final result:

List<String> list = stream.collect(Collectors.toList());
Set<String> set = stream.collect(Collectors.toSet());
String joined = stream.collect(Collectors.joining(", ", "[", "]")); // "[a, b, c]"
Map<String, Integer> map = stream.collect(Collectors.toMap(Person::name, Person::age));

groupingBy buckets elements into a Map<K, List<T>> (by default) keyed by a classifier function:

Map<String, List<Person>> byCity = people.stream()
    .collect(Collectors.groupingBy(Person::city));

With a downstream collector, each bucket can be further reduced instead of collected into a raw list:

Map<String, Long> countByCity = people.stream()
    .collect(Collectors.groupingBy(Person::city, Collectors.counting()));

Map<String, Double> avgAgeByCity = people.stream()
    .collect(Collectors.groupingBy(Person::city, Collectors.averagingInt(Person::age)));

partitioningBy is a specialized two-bucket groupingBy that splits elements into exactly Map<Boolean, List<T>> based on a Predicate — always produces both true and false keys, even if one bucket is empty:

Map<Boolean, List<Person>> adults = people.stream()
    .collect(Collectors.partitioningBy(p -> p.age() >= 18));
List<Person> minors = adults.get(false);

When to use which: groupingBy for classifying into an arbitrary number of buckets by any key; partitioningBy specifically for a binary yes/no split, which is both more explicit about intent and slightly cheaper than groupingBy with a boolean classifier.

stream.parallel() (or collection.parallelStream()) splits the underlying data source into chunks, processes each chunk concurrently across multiple threads (using the JVM-wide common ForkJoinPool, sized to the number of CPU cores by default), and merges the partial results — versus a sequential stream, which processes every element one at a time on the calling thread.

long count = list.parallelStream()
    .filter(x -> isExpensiveCheck(x))
    .count();

When parallel streams help: large datasets (thousands+ elements), CPU-bound per-element work (heavy computation, not I/O), and a data source that splits efficiently (arrays, ArrayList, ranges) — genuine multi-core speedup is possible in exactly this profile.

When to avoid parallel streams:

1. Small collections — the overhead of splitting work and coordinating threads easily exceeds any benefit; sequential is often faster for anything under a few thousand elements.
2. I/O-bound or blocking operations (network calls, file access, database queries) — these threads block, but they're borrowed from the shared common ForkJoinPool, which is used JVM-wide by all parallel streams and CompletableFuture.supplyAsync calls by default. Blocking those threads can starve unrelated parallel work elsewhere in the application.
3. Poorly splittable sources — LinkedList (no efficient random access, splits poorly) gains little or nothing from parallelism, unlike ArrayList or arrays.
4. Operations with side effects on shared mutable state — e.g., list.parallelStream().forEach(x -> sharedList.add(x)) on a non-thread-safe collection is a race condition; parallel streams don't make your lambda's side effects thread-safe.
5. Order-dependent operations — forEach on a parallel stream doesn't guarantee encounter order (use forEachOrdered if order matters, though that reduces the parallelism benefit).

Practical guidance: default to sequential streams; reach for .parallel() only after profiling shows a genuine CPU-bound bottleneck on a large enough dataset, and be mindful that it shares the same common pool as other parts of the application.

java.util.Date and Calendar (pre-Java 8) had well-known problems: Date is mutable (unsafe to share across threads or expose from an API without defensive copying), months are zero-indexed (Calendar.JANUARY == 0, a classic source of off-by-one bugs), and the API for basic arithmetic (adding days, comparing dates) is clunky and easy to misuse.

java.time (Java 8+, based on the well-regarded Joda-Time library) fixes this with a set of immutable, thread-safe types, each modeling a distinct concept:

LocalDate today = LocalDate.now();
LocalDate nextWeek = today.plusWeeks(1);       // fluent, immutable arithmetic
Period age = Period.between(birthDate, today); // date-based span

LocalDateTime dt = LocalDateTime.of(2026, 7, 4, 10, 30); // month = 7, not 6 — sane numbering
DateTimeFormatter fmt = DateTimeFormatter.ofPattern("yyyy-MM-dd");
String formatted = dt.format(fmt);

Key improvements over the legacy API: every type is immutable (every "modifying" method returns a new instance, safe to share across threads without synchronization), months/days use natural, human-numbered values, the API distinguishes clearly between date-only, time-only, and zoned concepts instead of forcing everything through one Date/Calendar pair, and DateTimeFormatter (also thread-safe, unlike the old SimpleDateFormat) handles parsing/formatting.

var (Java 10+) lets you omit an explicit type for a local variable, letting the compiler infer it from the initializer expression:

var list = new ArrayList<Map<String, List<Integer>>>(); // vs. spelling the type twice
var name = "Alice"; // still statically typed as String — var is not dynamic typing

Limitations:

• Only for local variables with an initializer — not for fields, method parameters, or return types.
• Requires an initializer (var x; alone doesn't compile — there's nothing to infer from).
• Can't be initialized to null directly (var x = null; doesn't compile — no type to infer).
• It's purely syntactic — the compiled bytecode is identical to writing the explicit type; var carries no runtime behavior difference and the variable remains fully statically typed.
• Overuse can hurt readability when the inferred type isn't obvious from the right-hand side (e.g., var result = process(x); hides what type result actually is without IDE assistance).

Text blocks (finalized in Java 15, triple-double-quote delimiters) let you write multi-line string literals without escaping every newline/quote or concatenating with +:

String json = """
    {
      "name": "Alice",
      "age": 30
    }
    """;

Text blocks automatically strip a common leading-whitespace margin (based on the closing delimiter's position) and normalize line terminators, making embedded JSON/SQL/HTML far more readable than an escaped one-liner. Limitations: you still need an escaped delimiter to include a literal triple-quote, a trailing backslash to suppress an unwanted trailing newline, and trailing whitespace on a line is stripped by default unless explicitly preserved with \s or \ escapes — a common surprise when trailing spaces are semantically significant.