Why should Java 8's Optional not be used in arguments

java

best-practices

performance

functional-programming

byAlex Kataev·Dec 22, 2024

Say no to Optional as a method parameter in Java 8. It brings extra baggage. Why? Because parameters can already be null, and adding Optional! is like adding another layer of wrapping to your christmas present 🎁 - exciting at first, but then you find out it's empty 🥴.

Save Optional for return types to explicitly broadcast the fact that a result might be MIA (Missing In Action).

Utilize method overloading or annotations to handle potential null party crashers. It feels more intuitive and less frustrating.

// Preferred. Like ordering a burger, with or without onions.
public void processOrder(Burger burger) {
    // Process non-null burgers...Yummy!
}

public void processOrder() {
    // Process when no burger is ordered...Who does that?!
}

Unboxing Optionals: A closer look

What's the point of Optional?

Let's get it straight - Optional is a showstopper for return types as confirmed by Brian Goetz himself. It's like wearing a suit to a beach party, it doesn't quite fit the Maybe monad vibe.

Optional as param vs method overloading

A face-off! But method overloading wins the match. Why? Clear, rudimentary code is Java's holy grail and method overloading fits the bill. Optional as a parameter is like going to a comedy club to watch a drama.

The performance plot twist

Did you ever try to stuff a genie back into a bottle? Using Optional as a parameter feels similar to the compiler. It's an abstraction, an unnecessary one. Beware of performance glitches!

The null fable of Optional

Java's version of inception is passing Optional parameters as null. Remember, we introduced Optional to avoid null pointer exceptions. Let's avoid shooting ourselves in the foot.

Let's not complicate simplicity

Java loves simplicity. Like pizza, the best is often the simplest. Optional as an argument tends to spice things up a bit more than necessary. So, let's not add pineapple to our pizza, shall we?

When life gives you multiple Optionals, use liftM2

Sometimes you cornered with multiple Optional parameters, use a functional approach with liftM2. It's like navigating a traffic jam using Google Maps🗺️.

Context matters: assessing Optional usage

When functional patterns make a cameo

Functional programming patterns often champion Optional, but it's best used in return values and not as a stage prop in method arguments. Java prefers its drama to be imperative.

Safety by the compiler

Introducing Optional in arguments is like asking your kids to remember to turn off the lights. A noble request, but often forgotten. Let the compiler (our responsible adult) manage this null situation.

Readability under siege

Too many overloaded methods? It's like having 10 remotes for one TV. Maybe Optional can simplify things. But remember, it's the nuclear option.

Returning collections over Optional

Design your methods to return empty collections rather than Optional if it's a multiple items scenario. It's like showing an empty wallet instead of saying you have no money.

Dealing with ancients and newbies

Coexisting with legacy systems

Sometimes we must venture into the null realm when dealing with legacy code. In such cases, use Optional sparingly, like a bridge between archaic and modern civilizations.

Keep client code clean

A neat method signature without Optional parameters ensures clients don't break a sweat while using your API. Remember, cleanliness is next to godliness.

Listening to external constraints

Adhering to team preferences and external constraints is key in choosing whether to use Optional or not. Imagine Optional as a controversial pizza topping within a group.

explain-codes / Java / Why should Java 8's Optional not be used in arguments

Linked

Using Java 8's Optional with Stream::flatMap



'optional.get()' without 'isPresent()' check



Should Java 8 getters return optional type?



How do I use optional parameters in Java?



Optional Methods in Java Interface

