How do you decide whether to return Optional.empty() or Collections.emptyList()?

I understand there are performance consequences associated with returning optionals. I know returning empty collections could potentially also harm performance but that can be avoided by returning immutable empty collections such as Collections.emptyList(). What other factors should be considered when deciding which to choose.

Any performance issues between Optional and an Empty-List will be utterly negligible for the vast majority of usage. Stop concentrating on such issues, since premature attempts at optimisation at this level invariably end up causing more problems (difficult to maintain code, etc) than any realistic gain.

A deeper question is why you reckon these two options are really equivalent.

Optional are best for capturing whether a single object has been returned or not.

Lists obviously return a number of objects.

My personal opinion is that since “a number” obviously includes Zero, I have no problem returning an empty list, and on the contrary would have a hard time justifying the IMHO over-engineered idea of returning an Optional<List>. There is nothing such an ugly construct provides that is not more cleanly supplied by testing “list.isEmpty()” , and/or the effectively no-operation of iterating (or streams) along that list.

Its a bit hard to imagine a JVM-application where performance overhead on that level matters. Perhaps if you build super-foundational basic components like implementations of List itself, which build on primitive java types only or some serialization frameworks which make crazy stunts in the realm of unsafe.

Both optional.empty() and Collections.emptyList() are constants as of my knowledge, so no performance overhead there. yep, also the mighty source confirms this:

public static final <T> List<T> emptyList() {
    return (List<T>) EMPTY_LIST;
}

public static<T> Optional<T> empty() {
    @SuppressWarnings("unchecked")
    Optional<T> t = (Optional<T>) EMPTY;
    return t;
}

What other factors should be considered when deciding which to choose.

I'm not so into philosophy of coding usually, but Optional says more "there can be either something or nothing whatsoever", but an empty list says "ok, its a list anyway, just of size zero". Just note that the constant EMPTY_LIST is immutable, you can't put anything into it.

I think, it happened that I did put lists into optionals to indicate some "nothing whatsoever there" or "doesn't apply at all" and this causes the tiny overhead of crating the optional object. But I doubt, that you'll find a reasonable application where that makes a meaningful difference. And I do agree with @racraman that an Optional<List> just looks weird and indicates some degenerate case that shouldn't be there in the first place. Don't know what the general consensus is on that detail, though.

E.g. here's a discussion of the topic claiming that the use of Optional is not optional, when the shunned alternative would be to return null. It also goes onto the details of Optional's interface and its use case. E.g issues of style arise, where Optional allows for "more functional" fluent coding style that seems popular at the moment.

And if you do care about performance on that level, which you probably shouldn't, that's a whole topic into itself, see e.g. this related article. There may be a case to be made that Optional using its fluent interface may outperform conditionals ("if") on modern cpus due to possible branch misprediction in that case.