DEV Community: André Borba

Surfing with FP Java - Mastering BiConsumer

André Borba — Fri, 25 Sep 2026 15:00:00 +0000

Introduction

In the last episode, BiPredicate evaluated two values together and returned a verdict.

Now, in our final stop, let's meet BiConsumer: it takes two inputs and performs an action, no result, just effect.

If Consumer acts on one value, BiConsumer acts on a pair.

What Is BiConsumer?

@FunctionalInterface
public interface BiConsumer<T, U> {

    void accept(T t, U u);

    default BiConsumer<T, U> andThen(BiConsumer<? super T, ? super U> after) {
        Objects.requireNonNull(after);
        return (t, u) -> {
            accept(t, u);
            after.accept(t, u);
        };
    }
}

Input: two objects, of types T and U.
Output: none (void).
Purpose: perform an action that depends on two values at once, typically with side effects.

Why Use BiConsumer?

Before, iterating a map and doing something with both key and value meant a hand-rolled loop:

for (Map.Entry<String, Integer> entry : stock.entrySet()) {
    System.out.println(entry.getKey() + ": " + entry.getValue());
}

BiConsumer turns that action into a first-class, reusable value, and Map.forEach accepts it directly:

BiConsumer<String, Integer> printStock = (item, qty) -> System.out.println(item + ": " + qty);

stock.forEach(printStock);

Practical Examples

1. Iterating a Map

Map<String, Integer> stock = Map.of("apples", 10, "bananas", 4);

stock.forEach((item, qty) -> System.out.println(item + ": " + qty));

2. Logging Pairs

BiConsumer<String, Integer> logLowStock = (item, qty) -> {
    if (qty < 5) System.out.println("Low stock: " + item);
};

stock.forEach(logLowStock);

3. Chaining with andThen

BiConsumer<String, Integer> print = (item, qty) -> System.out.println(item + ": " + qty);
BiConsumer<String, Integer> alert = (item, qty) -> {
    if (qty < 5) System.out.println("Alert! " + item + " is low");
};

BiConsumer<String, Integer> pipeline = print.andThen(alert);

pipeline.accept("bananas", 4);
// bananas: 4
// Alert! bananas is low

4. Event Handling with Two Parameters

BiConsumer<Order, String> onStatusChange = (order, newStatus) ->
    System.out.println("Order " + order.getId() + " -> " + newStatus);

onStatusChange.accept(currentOrder, "SHIPPED");

Real-World Patterns

Map Iteration: forEach over a Map is the most natural home for BiConsumer.
Contextual Callbacks: Passing both an event and its context to a handler in one call.
Coordinated Logging / Auditing: Recording two related pieces of information together, e.g. an entity and the action performed on it.
Two-Argument Event Handlers: Modeling listeners that need more than a single piece of data to act.

Best Practices

Isolate Side Effects: Keep a BiConsumer focused on one observable effect at a time.
Name Both Arguments' Role: onStatusChange, logLowStock communicate more than a generic handler.
Compose Carefully: Use andThen for a short, clear sequence of effects, not a long hidden chain.

Common Pitfalls

Thread Safety in Parallel forEach: A BiConsumer that mutates shared state can race when used with a parallel stream or a concurrent map.
Overuse for Transformation: If the goal is to produce a result, reach for BiFunction, don't smuggle a return value out through a captured variable.
Traceability: Multiple chained BiConsumers with side effects can make it hard to know, at a glance, everything a single accept() call actually does.

Functional Analogy

Think of BiConsumer as a two-person delivery:

Two packages arrive together, T and U.
Both get handled in the same visit.
Nothing is handed back, the effect is what mattered.

Conclusion

BiConsumer closes the loop on Java's core functional interfaces. Across ten episodes, we've covered every shape a single or paired value can take: a decision (Predicate, BiPredicate), a transformation (Function, BiFunction, UnaryOperator, BinaryOperator), an action (Consumer, BiConsumer), and a source (Supplier). Together, they form a small but complete vocabulary for functional Java.

What's Next

With all nine core interfaces covered, the next natural step is putting them to work together, composing predicates, functions, and consumers into a single real-world pipeline. That's where we're headed next: turning vocabulary into fluency. 🚀

Surfing with FP Java - Mastering BiPredicate

André Borba — Thu, 24 Sep 2026 15:00:00 +0000

Introduction

In the last episode, BiFunction combined two inputs into a transformed result.

Now, let's return to Predicate's territory, boolean logic, but this time evaluating two values together with BiPredicate.

If Predicate asks a question about one value, BiPredicate asks a question about a relationship between two.

What Is BiPredicate?

@FunctionalInterface
public interface BiPredicate<T, U> {

    boolean test(T t, U u);

    default BiPredicate<T, U> and(BiPredicate<? super T, ? super U> other) { ... }
    default BiPredicate<T, U> or(BiPredicate<? super T, ? super U> other) { ... }
    default BiPredicate<T, U> negate() { ... }
}

Input: two objects, of types T and U.
Output: a boolean.
Purpose: express a condition that depends on two values at once, not just one.

Why Use BiPredicate?

Before, relational checks between two values were usually buried inside an if statement:

if (startDate.isBefore(endDate)) {
    // valid range
}

BiPredicate promotes that check into a reusable, named, composable value:

BiPredicate<LocalDate, LocalDate> isValidRange = (start, end) -> start.isBefore(end);

System.out.println(isValidRange.test(startDate, endDate));

Practical Examples

1. Comparing Two Values Directly

BiPredicate<Integer, Integer> isGreater = (a, b) -> a > b;

System.out.println(isGreater.test(10, 5)); // true

2. Validating Related Fields

BiPredicate<LocalDate, LocalDate> isValidRange = LocalDate::isBefore;

boolean valid = isValidRange.test(order.getStartDate(), order.getEndDate());

3. Composition with and / or / negate

BiPredicate<String, String> sameLength = (a, b) -> a.length() == b.length();
BiPredicate<String, String> sameFirstChar = (a, b) -> a.charAt(0) == b.charAt(0);

BiPredicate<String, String> looksSimilar = sameLength.and(sameFirstChar);

System.out.println(looksSimilar.test("Borba", "Bruno")); // true

4. Matching Pairs While Filtering Manually

BiPredicate<String, Integer> stockIsLow = (item, quantity) -> quantity < 5;

stock.forEach((item, quantity) -> {
    if (stockIsLow.test(item, quantity)) {
        System.out.println("Low stock: " + item);
    }
});

Real-World Patterns

Field Validation: Checking that two related fields, like a date range or a min/max pair, are consistent with each other.
Matching Logic: Comparing two records to decide if they represent a match or a duplicate.
Filtering Map Entries: Combining a key and a value manually where Stream's single-argument filter doesn't apply directly.
Authorization Checks: Testing a user against a resource, e.g. BiPredicate<User, Document> canAccess.

Best Practices

Name for the Relationship: isValidRange, canAccess, matches say more than a generic check.
Keep It Side-Effect Free: A BiPredicate should only answer true or false, never perform an action.
Compose Small Predicates: Build complex relational checks out of and / or / negate rather than one large lambda.

Common Pitfalls

Forcing It Where Predicate Fits: If the second value is just a fixed constant, a plain Predicate with a captured variable is simpler.
No Direct Stream Integration: Stream.filter takes a Predicate, not a BiPredicate, adapting one to the other adds a layer of indirection worth naming clearly.
Deep Nesting: Combining many BiPredicates can hide the actual rule being tested, extract intermediate named predicates.

Functional Analogy

Think of BiPredicate as a judge in a duel:

Two contestants step forward, T and U.
The judge studies them together.
A single verdict comes back: true or false.

Conclusion

BiPredicate extends predicate logic into the space between two values, essential for validation, matching, and relational rules that a single-argument Predicate can't express.

What's Next

In our final stop, we'll meet BiConsumer, an interface that performs an action with two inputs and no result, closing our tour of Java's core functional interfaces.

Surfing with FP Java - Mastering BiFunction

André Borba — Wed, 23 Sep 2026 15:00:00 +0000

Introduction

In the last episode, BinaryOperator combined two values of the same type into one.

Now, let's generalize that idea with BiFunction: two inputs, possibly of different types, transformed into a result of yet another type.

If Function transforms one value, BiFunction transforms a pair.

What Is BiFunction?

@FunctionalInterface
public interface BiFunction<T, U, R> {

    R apply(T t, U u);

    default <V> BiFunction<T, U, V> andThen(Function<? super R, ? extends V> after) {
        Objects.requireNonNull(after);
        return (T t, U u) -> after.apply(apply(t, u));
    }
}

Input: two objects, of types T and U.
Output: one object of type R.
Purpose: transform a pair of values, possibly of different types, into a single result.

Why Use BiFunction?

Before, combining two independent pieces of data meant a bespoke method for every combination:

static String label(String name, int score) {
    return name + ": " + score;
}

BiFunction turns that combination logic into a value you can pass around:

BiFunction<String, Integer, String> label = (name, score) -> name + ": " + score;

System.out.println(label.apply("Borba", 95)); // "Borba: 95"

Practical Examples

1. Combining Two Inputs into a Result

BiFunction<Integer, Integer, String> describe = (a, b) -> a + " + " + b + " = " + (a + b);

System.out.println(describe.apply(2, 3)); // "2 + 3 = 5"

2. Map.merge and Map.compute

Map<String, Integer> stock = new HashMap<>();
stock.put("apples", 10);

BiFunction<Integer, Integer, Integer> addStock = Integer::sum;

stock.merge("apples", 5, addStock);
// stock: {apples=15}

3. Chaining with andThen

BiFunction<Integer, Integer, Integer> multiply = (a, b) -> a * b;

BiFunction<Integer, Integer, String> multiplyThenDescribe =
    multiply.andThen(result -> "Result: " + result);

System.out.println(multiplyThenDescribe.apply(6, 7)); // "Result: 42"

4. Building a Value Object from Two Sources

BiFunction<User, Order, Receipt> toReceipt = (user, order) ->
    new Receipt(user.getName(), order.getTotal());

Receipt receipt = toReceipt.apply(currentUser, currentOrder);

Real-World Patterns

Map Aggregation: Map.merge, Map.compute, and Map.computeIfPresent all take a BiFunction to combine or update values.
DTO / Record Assembly: Combining two independent objects, a user and an order, a request and a context, into one composed result.
Custom Reducers with Heterogeneous Types: Folding a stream of raw input into an accumulator of a different type.
Service Layer Methods: Many two-argument business operations can be expressed as a stored, reusable BiFunction instead of a fixed method.

Best Practices

Name for Both Inputs and the Result: toReceipt, mergeCounts, describe say more than apply.
Keep It Pure: Avoid mutating either input inside apply, return a new result instead.
Use andThen for Post-Processing: Instead of writing the follow-up transformation inline, compose it.

Common Pitfalls

Reaching for Three or More Arguments: The JDK stops at two, wrapping extra parameters into a BiFunction<T, U, R> via a map or array is a sign a small record or a dedicated interface would be clearer.
Generic Overload: Long chains of type parameters hurt readability, consider a named type instead.
Mixing in Side Effects: A BiFunction that both computes a result and logs, saves, or mutates blurs its contract.

Functional Analogy

Think of BiFunction as a chef:

Two ingredients come in, T and U.
The chef combines them.
A single dish comes out, R.

Conclusion

BiFunction generalizes two-argument transformation, essential wherever a result depends on combining two independent pieces of information. It's the two-argument counterpart to everything Function already taught us.

What's Next

In the next episode, we return to boolean logic with BiPredicate, testing two values together to decide true or false.

Surfing with FP Java - Mastering BinaryOperator

André Borba — Tue, 15 Sep 2026 15:00:00 +0000

Introduction

In the last episode, we mastered UnaryOperator, the specialist that transforms one value into another of the same type.

Now, let's go one step further with BinaryOperator: it takes two values of the same type and combines them into a single result, still of that type.

If UnaryOperator refines, BinaryOperator merges.

What Is BinaryOperator?

@FunctionalInterface
public interface BinaryOperator<T> extends BiFunction<T, T, T> {

    static <T> BinaryOperator<T> minBy(Comparator<? super T> comparator) {
        return (a, b) -> comparator.compare(a, b) <= 0 ? a : b;
    }

    static <T> BinaryOperator<T> maxBy(Comparator<? super T> comparator) {
        return (a, b) -> comparator.compare(a, b) >= 0 ? a : b;
    }
}

Input: two objects, both of type T.
Output: one object, also of type T.
Purpose: combine two values into a single value of the same type, the backbone of reduction.

Why Use BinaryOperator?

Before Java 8, combining values meant a loop with a mutable accumulator:

int total = 0;
for (int price : prices) {
    total = total + price;
}

With BinaryOperator, the combining rule becomes a reusable value:

BinaryOperator<Integer> sum = (a, b) -> a + b;

int total = prices.stream().reduce(0, sum);

Now sum can be tested, named, and reused, independent of any particular loop.

Practical Examples

1. Reduce with an Explicit BinaryOperator

BinaryOperator<Integer> sum = Integer::sum;

int total = List.of(10, 20, 30).stream()
    .reduce(0, sum);

System.out.println(total); // 60

2. minBy / maxBy

BinaryOperator<User> oldest = BinaryOperator.maxBy(Comparator.comparing(User::getAge));

User winner = oldest.apply(userA, userB);

3. String Merging

BinaryOperator<String> join = (a, b) -> a + ", " + b;

String csv = List.of("java", "kotlin", "clojure").stream()
    .reduce(join)
    .orElse("");

System.out.println(csv); // "java, kotlin, clojure"

4. Custom Combiners for Parallel Streams

BinaryOperator<Map<String, Integer>> mergeCounts = (m1, m2) -> {
    Map<String, Integer> merged = new HashMap<>(m1);
    m2.forEach((k, v) -> merged.merge(k, v, Integer::sum));
    return merged;
};

Real-World Patterns

Aggregation: Totals, averages, and counts built on top of reduce.
Merging: Combining two partial results from parallel computations back into one.
Tie-Breaking: Picking a winner between two candidates with minBy / maxBy.
Custom Combiners: Supplying the combiner argument in the three-argument overload of reduce, needed for parallel streams.

Best Practices

Keep It Associative: Especially for parallel streams, (a op b) op c must equal a op (b op c), or results become order-dependent.
Keep It Pure: A BinaryOperator should compute a value, not mutate either argument.
Name for the Combination: sum, merge, pickNewest describe intent better than combine.

Common Pitfalls

Non-Associative Operations: Subtraction or division break parallel reduce, since the JVM may group operations differently across threads.
Missing Identity Element: Forgetting a sensible seed value for reduce(identity, operator) can produce wrong results for empty inputs.
Confusing It with BiFunction: If the two inputs and the output aren't all the same type, that's a BiFunction, not a BinaryOperator.

Functional Analogy

Think of BinaryOperator as a river confluence:

Two streams of the same kind of water arrive.
They merge at one point.
A single stream of that same water continues onward.

Conclusion

BinaryOperator anchors reduction and combination logic in functional Java. It's the quiet engine behind sum, max, min, and every reduce call that folds a collection into a single value.

What's Next

In the next episode, we'll relax the same-type constraint entirely and meet BiFunction, an interface built for combining two values of different types into a result of a third type.

Surfing with FP Java - Mastering UnaryOperator

André Borba — Mon, 14 Sep 2026 15:00:00 +0000

Introduction

In the last episode, we mastered Supplier, the source that generates values from nothing.

Now, let's turn to UnaryOperator, a specialization of Function built for one very specific job: transforming a value into another value of the exact same type.

If Predicate decides, Function transforms, Consumer acts, and Supplier provides, then UnaryOperator refines. It takes something, and gives back more of the same kind, changed.

What Is UnaryOperator?

Here's the definition:

@FunctionalInterface
public interface UnaryOperator<T> extends Function<T, T> {

    static <T> UnaryOperator<T> identity() {
        return t -> t;
    }
}

Input: an object of type T.
Output: another object, also of type T.
Purpose: express a transformation that never changes the type, only the value.

Why Use UnaryOperator?

You could always write this with a plain Function<T, T>:

Function<String, String> trim = String::trim;

That works, but it doesn't say anything extra about the shape of the transformation, a reader still has to check both generic parameters to confirm they match. UnaryOperator states the contract directly:

UnaryOperator<String> trim = String::trim;

This one-type guarantee matters most where the JDK itself expects it, like List.replaceAll.

Practical Examples

1. In-Place List Transformation

List<String> names = new ArrayList<>(List.of("filipe", "andré", "borba"));

UnaryOperator<String> capitalize = s -> s.substring(0, 1).toUpperCase() + s.substring(1);

names.replaceAll(capitalize);
// [Filipe, André, Borba]

2. Simple Same-Type Math

UnaryOperator<Integer> increment = n -> n + 1;

System.out.println(increment.apply(41)); // 42

3. Composition (Inherited from Function)

UnaryOperator<String> trim = String::trim;
UnaryOperator<String> upper = String::toUpperCase;

Function<String, String> pipeline = trim.andThen(upper);

System.out.println(pipeline.apply("  borba  ")); // "BORBA"

4. Iterative Generation with Stream.iterate

UnaryOperator<Integer> doubleIt = n -> n * 2;

List<Integer> powersOfTwo = Stream.iterate(1, doubleIt)
    .limit(5)
    .toList();

System.out.println(powersOfTwo); // [1, 2, 4, 8, 16]

Real-World Patterns

In-Place Normalization: Trimming, upper/lower-casing, or sanitizing collections via replaceAll.
State Transitions: Modeling a value moving to the next state of the same type, e.g. an Order with an updated status.
Iterative Algorithms: Feeding Stream.iterate or recursive-style computations that keep producing the same type.
Configuration Overrides: Applying a same-type patch or decorator to a config or builder object.

Best Practices

Prefer Immutability: Return a new instance instead of mutating the input, especially for domain objects.
Reserve It for Same-Type Transforms: If input and output types differ, use Function<T, R> instead, don't force the fit.
Name for the Operation: increment, trim, capitalize communicate intent better than op.

Common Pitfalls

Silent Mutation: Since T equals T, it's tempting to mutate the argument directly instead of returning a new value, breaking purity.
Forcing the Fit: Wrapping a Function<T, R> as UnaryOperator<T> by ignoring a type mismatch defeats its purpose.
Overusing in Long Compositions: A long chain of andThen calls can become as unreadable as the imperative code it replaced.

Functional Analogy

Think of UnaryOperator as a polishing machine:

Raw material T goes in.
The machine reshapes it.
What comes out is still T, just refined.

Conclusion

UnaryOperator is Function's disciplined sibling; it exists to make same-type transformations explicit and safe. Wherever a value needs to become a better version of itself, in place, in a pipeline, or across iterations, UnaryOperator is the right tool.

What's Next

In the next episode, we'll meet BinaryOperator, a step further: instead of transforming one value, it combines two values of the same type into one. Get ready to reduce.

Surfing with FP Java - Mastering Supplier

André Borba — Wed, 10 Sep 2025 15:00:00 +0000

Introduction

In the last episode, we mastered Consumer, the functional interface for performing actions.

Now, let’s turn our focus to Supplier, the simplest yet most powerful interface for lazy value generation.

If Predicate decides, Function transforms, and Consumer acts, then Supplier is the source. It provides values on demand, without requiring input.

What Is Supplier?

Here’s the definition:

@FunctionalInterface
public interface Supplier<T> {
    T get();
}

Input: none.
Output: an object of type T.
Purpose: generate or supply values, often lazily or repeatedly.

Why Use Supplier?

Traditionally, values are produced eagerly:

String token = UUID.randomUUID().toString();

With Supplier, we can defer execution and encapsulate value creation:

Supplier<String> tokenSupplier = () -> UUID.randomUUID().toString();

System.out.println(tokenSupplier.get()); // A new token each call

This is especially powerful in lazy evaluation, configuration loading, testing, and dependency injection.

Practical Examples

1. Random or Unique Values

Suppliers naturally express randomness or unique generation:

Supplier<Integer> randomInt = () -> new Random().nextInt(100);

System.out.println(randomInt.get()); // e.g., 42
System.out.println(randomInt.get()); // e.g., 17

2. Deferred Initialization

Delay expensive computation until it’s needed:

Supplier<List<User>> heavyQuery = () -> database.fetchAllUsers();

// Nothing happens yet
List<User> users = heavyQuery.get(); // Query executes only here

3. Factories and Object Creation

Suppliers are elegant factories:

Supplier<User> newUser = () -> new User(UUID.randomUUID().toString());

User user1 = newUser.get();
User user2 = newUser.get();

4. Stream Integration

Suppliers work with Stream.generate to produce infinite sequences:

Supplier<String> uuidSupplier = () -> UUID.randomUUID().toString();

List<String> ids = Stream.generate(uuidSupplier)
    .limit(3)
    .toList();

System.out.println(ids); 
// [550e8400-e29b-41d4-a716-446655440000, ...]

Real-World Patterns

Configuration Providers:
Load config lazily when requested.
Caching with Lazy Evaluation:
Compute once, then reuse.
Dependency Injection:
Pass Suppliers instead of concrete objects for flexible object creation.
Testing and Mocking:
Suppliers make it easy to inject fake or mock data.

Best Practices

Keep Suppliers Pure: Avoid hidden side effects. Suppliers should primarily generate values.
Name Clearly: Use names like tokenSupplier, userFactory, configProvider.
Combine with Higher-Order Functions: Suppliers can be passed to methods to delay execution or customize behavior.

Common Pitfalls

Uncontrolled Infinite Streams: Stream.generate without a limit leads to infinite loops.
Heavy Logic Inside: Don’t hide complex operations inside Supplier#get(), it should be lightweight and predictable.
Side Effects: While possible, side-effect-driven suppliers (e.g., network calls) blur responsibilities. Prefer purity.

Functional Analogy

Think of Supplier as a well:

You don’t provide anything to it.
Each time you draw (get()), it gives you fresh water (T).
The well might be deep, infinite, or cached, but it always supplies.

Conclusion

Supplier is the lazy generator of functional Java.
It encapsulates value creation, supports lazy evaluation, and integrates seamlessly with streams, factories, and testing strategies.

By mastering Supplier, you unlock on-demand computation and flexible object creation.

What’s Next

In the next episode, we’ll dive into UnaryOperator, a specialized function for single-input transformations.
Where Function transforms from one type to another, UnaryOperator specializes in transforming within the same type, a cornerstone of functional composition.

Surfing with FP Java - Mastering Consumer

André Borba — Tue, 09 Sep 2025 11:00:00 +0000

Introduction

In the last episode, we explored Function, the transformer that converts inputs into outputs.

Now, let’s dive into Consumer, the functional interface designed for side-effect actions.

If Predicate decides, and Function transforms, then Consumer acts.

It consumes a value and performs an operation, printing, logging, storing, or triggering an event, without returning a result

What Is Consumer?

The definition:

@FunctionalInterface
public interface Consumer<T> {
    void accept(T t);

    // Composition method
    default Consumer<T> andThen(Consumer<? super T> after) { ... }
}

Input: an object of type T.
Output: none (void).
Purpose: perform an action, typically with side effects.

Why Use Consumer?

Before Java 8, side-effect actions like printing or logging were scattered inside loops:

for (String name : names) {
    System.out.println(name);
}

With Consumer, these actions become first-class citizens, making them reusable and composable:

Consumer<String> printName = System.out::println;

names.forEach(printName);

This decouples behavior definition from execution context.

Practical Examples

1. Printing and Logging

Consumer<String> printer = System.out::println;

List<String> names = List.of("Filipe", "André", "Borba");
names.forEach(printer);

2. Updating State (Carefully)

Consumers are useful for updates, though this introduces side effects, so use with caution:

Consumer<User> activateUser = user -> user.setActive(true);

users.forEach(activateUser);

3. Chaining Consumers

With andThen, you can build pipelines of actions:

Consumer<String> print = s -> System.out.println("Name: " + s);
Consumer<String> upperPrint = s -> System.out.println("Upper: " + s.toUpperCase());

Consumer<String> chained = print.andThen(upperPrint);

chained.accept("Borba");
// Output:
// Name: Borba
// Upper: BORBA

4. Event-Driven Style

Consumers integrate naturally with event systems:

Consumer<Order> processOrder = order -> System.out.println("Processing: " + order.getId());
Consumer<Order> sendNotification = order -> System.out.println("Notifying user...");

Consumer<Order> orderPipeline = processOrder.andThen(sendNotification);

orderPipeline.accept(new Order(42L));

Real-World Patterns

Logging Pipelines
Attach Consumers to stream processing for debugging or monitoring.
Callbacks
Pass Consumers as parameters to configure behavior dynamically.
Event Handlers
Model listeners as Consumers that accept an event and perform an action.

Best Practices

Isolate Side Effects
Keep Consumers focused and limit what they modify.
Name Actions Clearly
Names like logUser, sendEmail, or saveOrder communicate intent better than generic names.
Compose When Useful
Use andThen to build pipelines instead of nesting Consumers inside one another.

Common Pitfalls

Overuse in Pure Pipelines: Don’t rely on Consumers inside transformations (map, filter). They’re meant for effects, not transformations.

Hidden State Mutations: Consumers can easily break functional purity. Use them wisely.

Debugging Complexity: Multiple chained Consumers with side effects may complicate traceability.

Functional Analogy

Think of Consumer as a performer on stage:

It receives a script (T).
Acts it out (accept).
Doesn’t return anything, the impact is observable, not returnable.

Conclusion

Consumer embodies the side-effect boundary in functional Java.
While Predicate filters and Function transforms, Consumer executes actions, crucial for logging, event-driven designs, and orchestrating workflows.

Handled with discipline, Consumers provide e*xpressive, composable, and testable ways to model effects*.

What’s Next

In the next episode, we’ll explore Supplier, the interface for lazy value generation.
Where Function transforms input, Supplier creates values from nothing.

Get ready, we’re about to harness the power of on-demand computation. 🚀

Surfing with FP Java - Mastering Function

André Borba — Mon, 08 Sep 2025 11:00:00 +0000

Introduction

In the previous episode, we mastered Predicate<T>, the functional interface for declarative boolean logic.

Now it’s time to step into the transformer of data: Function<T, R>.

If Predicate answers the question “Is this valid?”, Function answers “How do I transform this into something else?”.

This interface is at the heart of functional programming in Java, powering data mapping, pipelines, and business transformations.

What Is Function?

The definition is straightforward:

@FunctionalInterface
public interface Function<T, R> {
    R apply(T t);

    // Composition methods
    default <V> Function<V, R> compose(Function<? super V, ? extends T> before) { ... }
    default <V> Function<T, V> andThen(Function<? super R, ? extends V> after) { ... }

    // Utility
    static <T> Function<T, T> identity() { ... }
}

Input: an object of type T.
Output: an object of type R.
Purpose: transform input into output.

Why Use Function?

Before Java 8, transformations often required inline logic tied directly to loops or service calls:

List<String> names = new ArrayList<>();
for (User user : users) {
    names.add(user.getName().toUpperCase());
}

With Function, transformation becomes first-class and composable:

Function<User, String> toUpperName = user -> user.getName().toUpperCase();

List<String> names = users.stream()
    .map(toUpperName)
    .toList();

Now, transformation logic is explicit, reusable, and testable.

Practical Examples

Basic Transformation Transform Integer to String:

Function<Integer, String> intToString = i -> "Number: " + i;

System.out.println(intToString.apply(10)); // Number: 10

2. Mapping Over Collections

With streams, map works directly with Function:

List<String> names = List.of("Hob", "André", "Borba");

Function<String, Integer> nameLength = String::length;

List<Integer> lengths = names.stream()
    .map(nameLength)
    .toList();

System.out.println(lengths); // [3, 5, 5]

3. Composing Functions

Use andThen or compose for pipelines:

Function<Integer, Integer> multiplyBy2 = x -> x * 2;
Function<Integer, Integer> square = x -> x * x;

Function<Integer, Integer> pipeline = multiplyBy2.andThen(square);

System.out.println(pipeline.apply(3)); // (3 * 2) ^ 2 = 36

andThen: apply first, then the next.
compose: apply in reverse order.

4. Using Identity

Sometimes we need a no-op function:

Function<String, String> identity = Function.identity();

System.out.println(identity.apply("Hello")); // Hello

Useful in generic pipelines when you don’t want transformations.

Real-World Patterns

1. DTO Mapping

Convert domain objects into Data Transfer Objects (DTOs).

Function<User, UserDTO> toDTO = user -> new UserDTO(user.getId(), user.getName());

2. Pipelines in Data Processing

Chain multiple transformations (e.g., ETL systems, stream processors).

Domain-Specific Rules

Represent calculations or policies declaratively (price -> price * discount).

Best Practices

Name Functions by Transformation: Good names communicate the intent: toDTO, toUpperName, calculateTax.
Leverage Composition: Build pipelines using andThen and compose rather than nesting lambdas.
Prefer Pure Functions: Keep Function free of side effects, this ensures predictability and testability.

Common Pitfalls

Hidden Side Effects: Don’t log, mutate state, or throw unchecked exceptions inside functions.
Over-Complex Pipelines: Too many composed functions can obscure readability. Split into intermediate named functions.
Type Mismatches: Remember Function is generic, mismatched types in composition often cause compilation errors.

Functional Analogy

Think of Function as a transformer in a factory line:

It takes raw material (T).
Transforms it into a finished product (R).
Can be chained with other transformers to build a pipeline.

Conclusion

Function is the backbone of data transformation in functional Java. By externalizing transformation logic, you can build declarative pipelines, clean business rules, and reusable mappings.

It elevates Java from imperative loops to functional, composable workflows.

What’s Next

In the next episode, we’ll explore Consumer, the interface for actions without return values.
If Predicate validates and Function transforms, Consumer executes.

Stay tuned, the FP toolbox is just getting started! 🚀

Surfing with FP Java - Mastering Predicate

André Borba — Thu, 21 Aug 2025 01:20:39 +0000

Introduction

Welcome to the first practical episode of Surfing with FP Java. Today, we’ll explore Predicate, the functional interface that introduces declarative boolean logic in Java.

At first glance, Predicate seems simple, it takes a value and returns true or false. But its impact is profound: it allows us to externalize conditions, compose business rules, reduce coupling, and write code that is reusable and testable.

What Is Predicate?

In its pure form:

@FunctionalInterface
public interface Predicate<T> {
    boolean test(T t);

    // Default methods for composition
    default Predicate<T> and(Predicate<? super T> other) { ... }
    default Predicate<T> or(Predicate<? super T> other) { ... }
    default Predicate<T> negate() { ... }

    // Handy static method
    static <T> Predicate<T> isEqual(Object targetRef) { ... }
}

Input: an object of type T.
Output: a boolean indicating if the condition is satisfied.

Why Use Predicate?

Traditionally, conditions in Java were written in an imperative style:

if (user.getAge() > 18 && user.isActive()) {
    // allowed
}

With Predicate, we transform this into a first-class function. This means we can pass, compose, and reuse the logic more elegantly:

Predicate<User> isAdult = user -> user.getAge() > 18;
Predicate<User> isActive = User::isActive;

Predicate<User> canAccess = isAdult.and(isActive);

Now canAccess is a reusable and composable rule, decoupled from the control flow.

Practical Examples

1. Filtering Collections

One of the most common uses is with Streams:

List<String> names = List.of("Andre", "Borba", "John", "Amanda", "Vlad");

Predicate<String> startsWithA = name -> name.startsWith("A");

List<String> filtered = names.stream()
    .filter(startsWithA)
    .toList();

System.out.println(filtered); // [Andre, Amanda]

2. Composing Conditions

Predicates let us create declarative business rules:

Predicate<User> isAdult = u -> u.getAge() >= 18;
Predicate<User> isActive = User::isActive;
Predicate<User> canAccess = isAdult.and(isActive);

List<User> usersAllowed = users.stream()
    .filter(canAccess)
    .toList();

This separates business rules from imperative control, improving clarity.

3. Negating Conditions

With negate(), you can easily invert logic:

Predicate<String> empty = String::isEmpty;
Predicate<String> notEmpty = empty.negate();

List<String> nonEmptyNames = names.stream()
    .filter(notEmpty)
    .toList();

4. Using isEqual

Predicate also provides a handy equality check:

Predicate<String> isEqualToAdmin = Predicate.isEqual("admin");

System.out.println(isEqualToAdmin.test("admin")); // true
System.out.println(isEqualToAdmin.test("user"));  // false

Real-World Patterns

Input Validation
Compose multiple predicates to validate DTOs or commands before persistence.
Feature Flags
Represent feature enablement logic declaratively.
Dynamic Filters
Build predicates at runtime to support dynamic API filters.

Best Practices

Name Predicates Clearly
Use domain-oriented names like isEligible or hasPermission instead of p1 or p2.
Prefer Composition Over Nesting
Combine with and, or, negate rather than writing nested if blocks inside lambdas.
Domain Isolation
Store reusable predicates as constants in utility classes or within domain services.

Common Pitfalls

Overuse: Not every condition needs to be extracted into a predicate.
Complexity: Too many chained predicates can hurt readability. Consider specialized classes if logic becomes too complex.
Performance: Each predicate in a chain is executed sequentially. Watch out in large pipelines.

Functional Analogy

Think of Predicate as the gatekeeper in your code:

It receives someone (T).
Decides if they are allowed in (boolean).
Can work alone (test) or cooperate with other gatekeepers (and, or).

Conclusion

Predicate is much more than a simple boolean function, it is the building block of declarative logic in Java. By mastering it, you can externalize rules, compose conditions, and write code that is more expressive, reusable, and clean.

What’s Next

In the next episode, we’ll explore Function<T, R>, the "transformer" of data.
Where Predicate answers “Is this valid?”, Function answers “How do I transform this into something else?”.

From here, functional composition becomes even more powerful. 🚀

Surfing with FP Java - The Beginning

André Borba — Thu, 24 Jul 2025 15:00:00 +0000

Welcome to Surfing with FP Java, a series crafted for developers who want to ride the waves of functional programming (FP) in Java with confidence and mastery. If you're passionate about writing cleaner, more expressive, and robust code, this journey is for you. Whether you're a seasoned Java engineer or a curious developer looking to deepen your understanding of functional paradigms, this series will equip you with the knowledge and practical skills to harness Java's functional interfaces to their fullest potential.

Who Is This Series For?

This series is designed for Java developers who are ready to elevate their craft by embracing functional programming. You might be:

A backend engineer building scalable, maintainable systems and seeking to leverage FP for cleaner designs.
A curious coder intrigued by how functional interfaces like Predicate, Function, or Consumer can transform your codebases.
A tech enthusiast who wants to understand the why, when, and how of functional programming in Java, with a focus on real-world applicability.

No matter your experience level, this series assumes you have a working knowledge of Java (preferably Java 8 or later) and a desire to explore functional programming with rigor and enthusiasm. We'll start with the fundamentals and progressively dive into advanced concepts, ensuring you gain a deep, practical understanding.

Why Functional Programming in Java?

Java, traditionally an object-oriented powerhouse, embraced functional programming with the introduction of Java 8's lambda expressions and functional interfaces. These tools allow us to write code that is more concise, declarative, and resilient to change. By adopting functional programming, we can:

Reduce Boilerplate: Replace verbose constructs with expressive lambda expressions and method references.
Enhance Readability: Write code that clearly communicates intent, making it easier for teams to collaborate.
Improve Maintainability: Leverage immutability and stateless operations to minimize side effects and bugs.
Boost Scalability: Design systems that are easier to parallelize and reason about, especially in modern, concurrent applications.

Functional interfaces are the backbone of this paradigm in Java. They provide a structured yet flexible way to apply functional programming principles, enabling us to create robust, reusable, and testable code. In this series, we'll explore how these interfaces can transform your projects, making them more modular, performant, and enjoyable to work on.

What Will We Cover?

In Surfing with FP Java, we’ll take a deep dive into Java’s functional interfaces, covering their theoretical foundations, practical applications, and real-world impact. Our journey will include:

Core Functional Interfaces: We’ll explore the building blocks of Java’s functional programming capabilities, including:
- Predicate<T>: Testing conditions with boolean logic.
- Function<T, R>: Transforming inputs into outputs.
- Consumer<T>: Performing actions without returning results.
- Supplier<T>: Generating values on demand.
- UnaryOperator<T>: Specializing functions for single-input transformations.
- BinaryOperator<T>: Combining two inputs of the same type.
- BiFunction<T, U, R>: Handling two inputs to produce a result.
- BiPredicate<T, U>: Testing conditions with two inputs.
- BiConsumer<T, U>: Performing actions on two inputs.
Foundational Concepts: We’ll establish a solid theoretical base, explaining why functional programming matters, how it aligns with principles like immutability and referential transparency, and when to apply these interfaces effectively.
Practical Applications: Each episode will include idiomatic Java code examples, showcasing how to use these interfaces in real-world scenarios, from stream processing to event-driven architectures.
Best Practices: We’ll discuss when to use each interface, common pitfalls to avoid, and how to balance functional programming with Java’s object-oriented roots.
Impact on Projects: We’ll highlight the tangible benefits of using functional interfaces, such as improved code quality, easier testing, and better performance in concurrent systems.

Why This Matters

Using functional interfaces isn’t just about writing “cool” code—it’s about building systems that are easier to reason about, maintain, and scale. By mastering interfaces like Predicate, Function, and Consumer, you can:
Streamline Data Processing: Combine functional interfaces with Java Streams to write declarative, efficient pipelines.

Enhance Modularity: Create reusable, composable components that adhere to SOLID principles and Domain-Driven Design (DDD).

Reduce Bugs: Minimize side effects by favoring stateless operations and immutability.

Future-Proof Your Code: Prepare your projects for modern paradigms like reactive programming (e.g., with Spring WebFlux) and event-driven systems.

Whether you’re working on microservices, data pipelines, or enterprise applications, functional programming in Java empowers you to write code that is both elegant and robust.

What to Expect in This Series

Each episode of Surfing with FP Java will blend theory, practical examples, and real-world insights. We’ll start with foundational episodes that introduce each functional interface, then progress to advanced topics like combining interfaces, optimizing performance, and integrating FP with frameworks like Spring or Akka. Expect:

Step-by-Step Explanations: We’ll break down complex concepts with clear, rigorous reasoning (Chain-of-Thought style).
Idiomatic Code: All examples will be written in Java, following best practices and emphasizing security, readability, and performance.
Real-World Scenarios: From filtering data with Predicate to building reactive pipelines with Function, we’ll show how these interfaces solve practical problems.
Community Engagement: This series is for the tech community, so we’ll encourage feedback to refine and expand our content.

Let’s Ride the Wave!

Surfing with FP Java is more than a tutorial, it’s a journey to unlock the full potential of Java’s functional programming capabilities. In the upcoming episodes, we’ll dive into each functional interface, starting with Predicate and building toward advanced compositions and patterns. By the end of this series, you’ll have a comprehensive understanding of how to wield these tools to create elegant, high-performance systems.

Ready to catch the functional programming wave? Let’s dive in and start surfing with FP Java!

Next Episode: Stay tuned for “Surfing with FP Java - Mastering Predicate”, where we’ll explore the power of boolean logic in functional programming and how to use Predicate to write declarative, reusable code.

Clojure Is Awesome!!! [PART 23]

André Borba — Tue, 22 Jul 2025 15:00:00 +0000

But What If KISS? 👀

(ns clojure-is-awesome.kiss
  (:require [clojure.spec.alpha :as s]))

(s/def ::id string?)
(s/def ::type #{"work" "break"})
(s/def ::duration (s/and int? pos?))
(s/def ::start-time #(instance? java.time.Instant %))
(s/def ::end-time #(instance? java.time.Instant %))
(s/def ::status #{:running :completed :paused :cancelled})
(s/def ::session (s/keys :req-un [::id ::type ::duration ::start-time ::end-time]))
(s/def ::sessions (s/coll-of ::session :kind vector))

(defn create-session
  "Creates a Pomodoro session with computed end-time."
  [id type duration]
  (let [start-time (java.time.Instant/now)
        end-time (.plusSeconds start-time (* duration 60))
        session {:id id
                 :type type
                 :duration duration
                 :start-time start-time
                 :end-time end-time}]
    (if (s/valid? ::session session)
      session
      (throw (ex-info "Invalid session" {:errors (s/explain-data ::session session)})))))

(defn set-session-status
  "Sets a session’s status (e.g., paused, cancelled)."
  [session status]
  {:pre [(s/valid? ::status status)]}
  (assoc session :status status))

(defn session-status
  "Returns session status and remaining time as data, given current time."
  [session now]
  {:pre [(s/valid? ::session session)
         (instance? java.time.Instant now)]}
  (if (:status session)
    {:status (:status session) :remaining-minutes 0}
    (let [end-time (:end-time session)
          remaining-secs (max 0 (- (.getEpochSecond end-time) (.getEpochSecond now)))]
      {:status (if (pos? remaining-secs) :running :completed)
       :remaining-minutes (int (/ remaining-secs 60))})))

(defn format-session
  "Formats a session’s status for display."
  [session now]
  (let [{:keys [status remaining-minutes]} (session-status session now)]
    (str (:id session) ": " (:type session) " "
         (case status
           :running (str "running, " remaining-minutes " minutes remaining")
           :completed "completed"
           :paused "paused"
           :cancelled "cancelled"))))

(defn generate-report
  "Generates a status report for all sessions."
  [sessions now]
  {:pre [(s/valid? ::sessions sessions)
         (instance? java.time.Instant now)]}
  (str "Pomodoro Status Report\n"
       (apply str
              (map #(str (format-session % now) "\n") sessions))))

(comment
  (def sample-sessions
    [(create-session "s1" "work" 25)
     (create-session "s2" "break" 5)])

  (session-status (first sample-sessions) (java.time.Instant/now))
  ;; => {:status :running, :remaining-minutes 25} (or less, depending on timing)

  (generate-report sample-sessions (java.time.Instant/now))
  ;; => "Pomodoro Status Report\ns1: work running, 25 minutes remaining\ns2: break running, 5 minutes remaining"

  ;; Simulate paused and cancelled states
  (def paused-session (set-session-status (first sample-sessions) :paused))
  (session-status paused-session (java.time.Instant/now))
  ;; => {:status :paused, :remaining-minutes 0}

  ;; Simulate completed session (adjust start-time for testing)
  (def completed-session
    (assoc (second sample-sessions)
           :start-time (.minusSeconds (java.time.Instant/now) (* 6 60))))
  (session-status completed-session (java.time.Instant/now))
  ;; => {:status :completed, :remaining-minutes 0}
)

Clojure Is Awesome!!! [PART 22]

André Borba — Mon, 21 Jul 2025 15:00:00 +0000

What If DRY? 👀

(ns clojure-is-awesome.dry
  (:require [clojure.spec.alpha :as s]
            [clojure.string :as str]))

(s/def ::id string?)
(s/def ::amount (s/and number? pos?))
(s/def ::date #(instance? java.time.LocalDate %))
(s/def ::category #{"income" "expense"})
(s/def ::description (s/and string? #(not (str/blank? %))))
(s/def ::transaction (s/keys :req-un [::id ::amount ::date ::category ::description]))
(s/def ::transactions (s/coll-of ::transaction :kind vector))

(defn create-transaction
  "Creates a transaction with centralized spec validation."
  [id amount date category description]
  (let [transaction {:id id :amount amount :date date :category category :description description}]
    (if (s/valid? ::transaction transaction)
      transaction
      (throw (ex-info "Invalid transaction" {:errors (s/explain-data ::transaction transaction)})))))

(defn calculate-by-category
  "Calculates totals for a given category."
  [transactions category]
  (->> transactions
       (filter #(= (:category %) category))
       (map :amount)
       (reduce + 0)))

(defn format-transaction
  "Formats a transaction for display."
  [transaction]
  (str (.toString (:date transaction)) " - " (:category transaction) " - " (:description transaction) ": $" (:amount transaction)))

(defn generate-report
  "Generates a financial report with reusable, composable functions."
  [transactions]
  {:pre [(s/valid? ::transactions transactions)]}
  (let [income (calculate-by-category transactions "income")
        expenses (calculate-by-category transactions "expense")
        balance (- income expenses)
        formatted-transactions (map format-transaction transactions)]
    (str "Financial Report\n"
         "Total Income: $" income "\n"
         "Total Expenses: $" expenses "\n"
         "Balance: $" balance "\n"
         "Transactions:\n"
         (str/join "\n" formatted-transactions))))

(comment
  (def sample-transactions
    [(create-transaction "t1" 1000 (java.time.LocalDate/of 2025 7 1) "income" "Salary")
     (create-transaction "t2" 200 (java.time.LocalDate/of 2025 7 2) "expense" "Groceries")
     (create-transaction "t3" 500 (java.time.LocalDate/of 2025 7 3) "income" "Freelance")
     (create-transaction "t4" 150 (java.time.LocalDate/of 2025 7 4) "expense" "Utilities")])

  (calculate-by-category sample-transactions "income")  ;; => 1500
  (calculate-by-category sample-transactions "expense") ;; => 350
  (generate-report sample-transactions)
  ;; => "Financial Report\nTotal Income: $1500\nTotal Expenses: $350\nBalance: $1150\nTransactions:\n2025-07-01 - income - Salary: $1000\n2025-07-02 - expense - Groceries: $200\n2025-07-03 - income - Freelance: $500\n2025-07-04 - expense - Utilities: $150"
)