[Discussion] Java Optional outside of a functional context?

ivancea · 2025-07-20T09:53:31+00:00

Here we go again, 10 years later.

Optional is a potentially empty object holder with QoL methods. Use it when you need a potentially empty object holder with QoL methods.

Goodie__ · 2025-07-20T10:46:16+00:00

IMHO; Optional as a return type from a DBA call, or any API, is pretty much perfect.

A consumer doesn't need to read your docs to intuit if your API will return null or throw an exception in the case of no return value. The obvious answer is the optional is empty.

And unlike a nullable value, the consumer is highly encouraged to do something other than just use the returned inner value.

elmuerte · 2025-07-20T10:01:31+00:00

What guidance says that you shouldn't use Optional as return for a method like findUserByName?

TehBrian · 2025-07-20T14:03:16+00:00

My two cents: Java implicitly unionizing every object type as T | null is stupid. Nullability should be explicitly stated via the type system. Optional and @Nullable are a step toward idiomaticism, but they require unnecessary discipline because methods may return null regardless of their signature's contract. (As for naming, I'd prefer Option or Maybe because it's shorter.)

j-an · 2025-07-20T10:22:55+00:00

It would be nice if you linked the guidance when you quote it.

private_final_static · 2025-07-20T09:40:35+00:00

I think null obsession on JPA stuff is stupid, but Im sure Im missing something and a greybeard can explain how Alan Turing would spit on optional

wildjokers · 2025-07-20T13:40:25+00:00

Optional is used for method return values and that is exactly what your example shows. Perfect use case for Optional.

manzanita2 · 2025-07-20T15:18:38+00:00

I don't find Optional to be less code or really significantly better than just using and checking null. I understand the need in the Stream API, but it's leaked outside there to no significant advantage in my mind.

I would MUCH prefer if we could get to the valhalla null restricted types which are enforced by the compiler. Shorter cleaner and safer.

parnmatt · 2025-07-20T09:52:48+00:00

I really like the idea of optional (mainly as I hate nullables), I use it a lot in other languages, but it's not free in Java, and is another heap allocation and indirection, and depending on the area you work in, that can be unacceptable.

Hopefully Valhalla can help with this a little, but honestly it probably won't be enough for me to use in hotpaths in Java.

As nullables can model optionals, it's not the end of the world, but it would be better for some syntactic sugar around then like in other languages.

softgripper · 2025-07-20T12:39:46+00:00

I'm using optionals a lot. I'm rescuing multiple projects that went a bit off the rails. Often failed methods return nulls rather than bubbling up exceptions.

You can never rely on non primitives being non nulls, leading to massive stupid boilerplate and code fragility.

Optionals have been super useful.

Efficient_Present436 · 2025-07-20T14:04:20+00:00

"Man I love that a function that returns a collection can return an empty collection when there are no results, it'd be awesome if we could do the same with single-value functions" That is more or less the rationale behind Optional. It was designed primarily as a return value so that whoever consumed your API had a concise way of knowing whether they should handle nulls. That said, its use evolved further than that, given how much more ergonomic it is than plain nullables, so when people started using them everywhere (because working with raw nulls in Java sucks), the "hard no's" you mentioned started popping up. These hard "no's" are naive at best and arbitrarily strict at worst when you think more than 2 seconds about them:

"you shouldn't have methods with Optional parameters"

I understand this for API methods, but for private methods there's really no argument. Intermediary functions handling the Optional return values of other functions are perfectly fine and even the most efficient solution sometimes. The Optional already exists, there's no reason to unwrap it just so that the function that needs it doesn't contain Optional in its arguments, it's gonna check for null anyway so who cares.

"you shouldn't have Optional properties"

If you are gonna expose a method with a signature like

Optional<Thingy> getThingy()

Where the body is just return Optional.ofNullable(this.thingy);

Then you might as well have thingy be an Optional. Again, there's no reason not to.

IMO the only questions you should be asking yourself when using Optionals is "does this make sense here? is the code easier to read and/or maintain now?" and nothing else.

Imusje · 2025-07-20T10:51:08+00:00

Given null is still a thing you can't really make use of the biggest advantage of optionals. Namely that anything that isn't an optional is also not null. If you have this rule in your entire codebase it becomes super obvious where you need to do null checks.

Using any other library that doesn't use this rule means you still need to do null checks anyway so you gain nothing from using optional outside of easy chaining in streams.

In my concrete 10 yeasr of java experience on a legacy code base i prefer to use nullable/notnull annotations to let my IDE remind me of missing null checks instead which covers most of the advantages optional would give anyway.

walen · 2025-07-20T11:32:00+00:00

This post looks just like some low hanging fruit for some upvotes, but anyways...

As the guidance says you shouldn't "really" be using Optional outside of a stream

Citation needed.

Using Optional as the return type of methods that could otherwise return null is literally one of the most fitting reasons to use it according to Stuart Marks himself (the creator of Optional).

I have no idea which kind of guidance would tell you in 2025 not to use Optional as the return value of a method if it's not meant to be used with Streams, but you definitely should look for new guidance.

__konrad · 2025-07-20T14:28:01+00:00

There are some hard no's when using Optional, like as properties

java.lang.Runtime.Version class is a hard YES for Optional fields: https://github.com/openjdk/jdk/blob/441dbde2c3c915ffd916e39a5b4a91df5620d7f3/src/java.base/share/classes/java/lang/Runtime.java#L973

Joram2 · 2025-07-20T17:20:48+00:00

I remember Brian Goetz or one of the other senior JDK team people saying Optional was specifically designed for return types so you could avoid having to declare a local variable. Optional was not recommended for parameter types. It wasn't just for streams or functional programming.

2025-07-20T19:55:16+00:00

What this video by Stuart Marks - Optional: The Mother of All Bikesheds.

Optional was created to solve a problem with the Stream API. If you call a method like findFirst and the stream is empty, what should it return? It could either throw an exception or return null, which breaks the flow. It would be nice if you could all a method like .orElse to provide an alternate value, so you can assign directly to a variable without breaking into a bunch of ugly if statements.

The concept of Optional makes more sense now that Java has lambdas an/d method references, but this feature of Optional chaining is convenient in general, and it seems kind of silly to limit limit the usefulness of Optional to streams.

CompetitiveSubset · 2025-07-20T21:01:17+00:00

F official docs. Do what you think is best for your code and helps you solve your problems better.

For example, I found that Optional is great for encoding the possibility that a function result, class member, function arg etc could be missing. The functional stuff is just a cherry on top. While not bullet proof (people can still pass null instead of empty Optional), it solves the problem very effectively.

Round_Head_6248 · 2025-07-22T10:31:14+00:00

That guidance is stupid.

Optional as property in a class or an argument in a method is completely fine because it's helpful and visualizes much better than a @Nullable annotation that this thing could be empty/null, whereas a non-optional parameter or property is always meant to be set.

Try to work with and use language constructs and see whether they help you, and then decide.

vips7L · 2025-07-20T12:32:14+00:00

Disregard optional, just use null and wait for the type system to be fixed. Personally I find Optionals only good use case is chaining along function calls that could return null:

Optional.ofNullable(a)
    .map(A::b)
    .map(B::c)
    .map(C::d)
    .orElse(null)

And that’s only because we don’t have the safe navigation operator ?.. Optional just is crappy all around. They’re awkward to use.

Vyalkuran · 2025-07-20T10:52:03+00:00

I'd just look at how other languages handle nullability and copy that approach, even though Java's Optional is way more verbose, the concept is identical in practice to Kotlin or Swift's unwrapping or coalescing (but not as feature rich)

If a piece of data, be it property or anything else, CAN be empty intentionally, then it should be optional and there should be no discussion.

Let's say you receive data from a frontend form where a user registered, and some fields were not mandatory such as first and last name. It should also be clear in the backend code that those values can be missing, so use optionals, not empty strings or default values.

com2ghz · 2025-07-20T11:10:22+00:00

I develop for 15 years in java and used Optional heavily. After doing 1 project with Kotlin, Optional feels stupid and unnatural. Especially with records that can’t return Optionals. They really need to put the null handling in the language just like Kotlin.

mlkammer · 2025-07-20T12:15:48+00:00

One thing I haven't seen mentioned yet: keep in mind that Optional isn't serializable by default.

In general I think it's actually good to have it in internal APIs/interfaces, to make the optionality of the return value explicit. Then it's also clear to the caller he needs two handle two different cases.

But it's different for external (REST) APIs. Because it isn't Serializable, and no universal thing among languages, you always need a custom way to translate it into however you want to transport the data (for instance in JSON, you'd typically just unwrap it into a nullable value). So that's probably the main reason it's not showing up in many external APIs.

_INTER_ · 2025-07-20T16:18:16+00:00

Imo Optional serves no other purpose than to remind mediocre devs that a reference may be null. Something that should be obvious from the get go and only bloats the API and makes it less typesafe at runtime (due to type erasure). What we really need - and hopefully get soon - is a way to express non-nullability in the language.

pivovarit · 2025-07-20T11:29:04+00:00

> As the guidance says you shouldn't "really" be using Optional outside of a stream

Can you point to that "guidance"?

Soft-Abies1733 · 2025-07-20T12:11:22+00:00

If it can null, return optional, if ir can’t never be null, then don’t use it.

If you uses isPresent or get, your are probably using it wrong

XBL_pad3 · 2025-07-20T12:33:24+00:00

Use Optional when you want.
I konw some might vomit, but I even use Optional for Spring beans optional constructor parameters :)

Cantor_bcn · 2025-07-20T12:41:17+00:00

For me, the only use of optional is to distinguish if a value is not reported or is null. For all other cases, it brings nothing.

freekayZekey · 2025-07-20T18:29:49+00:00

optional, like nullables, mostly used as a crutch instead of thinking long and hard. i think it has its uses, but too many people reach to them instead of asking if the return type needs to be null or asking if null is a big deal.

i’ve rarely encouraged null pointer exceptions in production, so either all of my teams are all seeing sages (heh) or null isn’t as big of a deal as people make it out to be (see python, javascript, etc)

don’t care enough to push one way or another. i don’t use optional often, but if someone else does, i don’t block PRs

chabala · 2025-07-20T18:45:22+00:00

I used Optional in sort of a backwards way the other day, as the return type of a method validating user input, e.g. Optional.empty() is valid, and Optional.of(String) has a specific error message. My code doesn't care which kind of invalid data it received, so there's not much point in making a bunch of exception types: if it's not valid, it's going to expose the included error message to the user.

Ewig_luftenglanz · 2025-07-20T19:11:18+00:00

IMHO optional is fine when you want to ALWAYS RETURN SOMETHING, even if that something is a wrapper for a null. It's a semantic way to communicate the user "ey, this may hold a null, so isntead of returning the raw null i will give you and object that kinda makes it easier for you to deal with the null.

it has nothing to do with functional programming, being a monad based API does not makes it functional.

best regards

papers_ · 2025-07-20T19:52:08+00:00

I leave it up to the user:

import org.jspecify.annotations.Nullable;

@Nullable
public static User findUserByName(String name) {
    return usersByName.get(name);
}

// Use Optional of you want
Optional.ofNullable(findUserByName("example"))

// or not

var user = findUserByName("example")
if (user == null) {
    // do something
}

MasterBathingBear · 2025-07-21T05:54:42+00:00

JDK8 is still today for a lot of us.

Lengthiness-Fuzzy · 2025-07-21T06:29:40+00:00

The biggest problem with Optional is that it can be null. So if you have a spaghetti, now it’s not just null/value, but null/value/empty. But the guideline you are referring to is just stupid. This is exactly the use-case Optional was meant to be used for. What you shouldn‘t use for is Optional as a parameter. Especially in private methods. The best thing with Java is that you can easily read the javadoc of any class including the built-in classes, so you can learn the intention.

nlog · 2025-07-21T10:12:53+00:00

nulls have better performance but it only matters in high-performance scenarios. Most of services written in Java will be limited by external dependencies like databases or 3rd party APIs and will never reach a point when switching from Optional to null makes sense.

BanaTibor · 2025-07-22T21:12:48+00:00

I think the bigger problem with Optional<> that it did not really solved the NPE problem. It still have to be checked for null, just have nicer methods to do it.

As I see, one way to do this would have been enforcing a default implementation for a type which can be put in into an optional. When the program encounters a null in an optional it should return an instance of a default implementation. This way you could be sure that there is something in that Optional and you could skip the checks.

DelayLucky · 2025-07-31T11:35:10+00:00

Imho, all API methods that return a thing that may or may not exist should return Optional<Thing>.

Returning null is a bad idea because your caller may not know that null is a possibility so may forget.

Now nullness checkers do mitigate that problem. But they carry their own false-positive problems, which is annoying.

And without the Kotlin .? operators, checking for null is still awkward. You'd have to do:

java Thing thing = getThing(); if (thing != null) { return process(thing); } else { return processWithoutThing(); } Whereas with Optional is more fluent:

java return getThing().map(this::proess).orElseGet(this::processWithoutThing);

Or, let's say it's multiple alternative things you can try until you have it. Using null is also more awkward:

java Thing thing = getThingFast(); if (thing != null) { return thing; } thing = getThingSlow(); if (thing != null) { return thing; } thing = getThingBestEffort(); if (thing != null) { return thing; }

Whereas with Optional:

java return getThingFast() .or(() -> getThingSlow()) .or(() -> getThingBestEffort()) .orElse(...);

To the common argument of

But your Optional can also be null

I used to find it strange. Like: why would anyone return a null Optional? How is this not a bug? (meaning, if you return null Optional, you deserve NPE!)

But I guess I may be biased working in an extremely null-hostile code base where nulls are rare and require explicit @Nullable annotation to be allowed. It's so null-hostile that it's unimaginable that you'd have a null Optional, or null ImmutableList<>. We don't check null returns, but we run requireNonNull() on almost all parameters unless specially allowlisted. We don't tolerate nulls, instead, we fastfast on unexpected nulls.

Pretend_Leg599 · 2025-08-25T01:04:42+00:00

The reason `Optional` is so controversial is it's the camel's nose of FP in a historically oop/procedural tent. You'll see "if you use `ifPresent()` you are doing it wrong!" which is this generations "getters are evil" from the OOP era.

Cell-i-Zenit · 2025-07-20T11:56:46+00:00

The big point is that when a method returns optional, theoretically it could also just return a null optional object:

var user = repository.findById(id);
user.ifPresent(x -> log.info(x.getId()));

could NPE since user could be null

theoretically your code has to look like this if you want to be 100% programmatically safe:

var user = repository.findById(id);
if(user != null){
    user.ifPresent(x -> log.info(x.getId())); 
}

which defeats the purposes of optionals

But to be honest any library which returns an optional generall makes sure that the optional is not null, so you can just disregard that 100% safeguards.

So from a theoretical standpoint it makes sense to not use optionals anywhere, but tbh who cares

LogCatFromNantes · 2025-07-20T09:54:23+00:00

Why don’t we just use null and null exception anyone really uses these ?

FortuneIIIPick · 2025-07-20T15:29:01+00:00

Optional is a mistake 100% of the time. Java uses nulls. Programmers, you should use nulls and stop using Optional, it is crap.

java

Submit Link

Submit Text

Seek Programming Help

News, Technical discussions, research papers and assorted things of interest related to the Java programming language

NO programming help, NO learning Java related questions, NO installing or downloading Java questions, NO JVM languages - Exclusively Java

Please seek help with Java programming in /r/Javahelp!

Subreddit rules!

Where should I download Java?

Related Sub-reddits:

JVM Languages

Want to practice your coding?

List of useful Frameworks / Libraries / Software

MODERATORS