Oh, those coding styles are to be taken with a bit of salt.

1. (+) Passing an Optional result to another method, without any semantic analysis; leaving that to the method, is quite alright.
2. (-) Using Optional parameters causing conditional logic inside the methods is literally contra-productive.
3. (-) Needing to pack an argument in an Optional, is suboptimal for the compiler, and does an unnecessary wrapping.
4. (-) In comparison to nullable parameters Optional is more costly.
5. (-) The risk of someone passing the Optional as null in actual parameters.

In general: Optional unifies two states, which have to be unraveled. Hence better suited for result than input, for the complexity of the data flow.

The designers of Optional explicitly warn against using it as method parameters (e.g. https://stackoverflow.com/a/26328555).

Whether something is "OK to use" depends on intent, team coding practices, common programming idioms, and how strictly you want to adhere to API guidelines.

First, the facts about Optional<T>:

A container object which may or may not contain a non-null value.

...

API Note:

Optional is primarily intended for use as a method return type where there is a clear need to represent "no result," and where using null is likely to cause errors. A variable whose type is Optional should never itself be null; it should always point to an Optional instance.

^{Source: Oracle Java 11 JDK documentation (emphasis, mine)}

Not a lot of concrete guidance here beyond the recommendation that Optional<T> be used as a return type. In a strict sense, you are not using this as a return type, therefore the answer is "no, this is not OK." On the other hand, you are using it as the type for a field which may contain null. So you seem to satisfy the first part.

But it works.

That's why it's important to remember these are guidelines. The mechanics of whether you can use something are a different discussion, and hence, your question. Instead, I like to see how these optional fields are being used to ensure a more suitable OO design doesn't already exist.

If I had to look at a codebase that was peppered with field.ifPresent(foo -> foo.method()) every time field was used, I would start to wonder if we have a design problem with field rather than it's type. Even in cases where you have field.isPresentOrElse(foo -> foo.method(), () -> something else), I still think we are missing something. Frankly, the constant calls to the Optional<T> methods as a round-about way to avoid NullPointerExceptions makes me think the Null Object Pattern might be a better choice here. Every method in the "null object" can be a no-op. Getters can return pre-canned values (whatever the "or else" part of Optional.ifPresentOrElse() would have returned).

I don' like optional dependencies because they can be null, so now I need to incessantly check for null, or I need to use some other non-idiomatic construct like Optional<T> with a bunch of pass-through method calls in lieu of null-checks.

Code is much cleaner if you can simply call field.method() rather than field.ifPresent(foo -> foo.method()).

Some additional notes:

• The guidance in this answer applies best to situations where the T is a complex type. When T is a string, boolean, or numeric type, then the "optional" part of an Optional<T> becomes meaningful. An Optional<boolean> can be true, false, or not present, which your application could interpret as "not specified." In that case, document this fact on the field.

  • In the case of a String, consider defaulting to an empty string instead. No need for null if you have proper encapsulation. A constructor or setter can enforce the "empty string instead of null" constraint.

• When T is a complex type, consider other, more straight-forward designs first before resorting to an Optional<T>, if for no other reason than the Principle of Least Astonishment.

• Choose code that is easy to read first. In situations like this, I like to write the same code multiple ways. Consider writing it when checking for nulls, using another more suitable design pattern (like Null Object Pattern), and using an optional. Same code. 3 different styles. Which one do you like?

  • And then present the same 3 styles to a colleague to see which one they like.

In the end, you get working code either way. Personal taste, other object-oriented design practices and team habits play a bigger role in this decision than API guidance.

In general, Optional has a restricted set of use cases and is in danger of being overrused. You can refer to this answer by Java author Brian Goetz to understand these (emphasis added):

But we did have a clear intention when adding this [java.util.Optional] feature, and it was not to be a general purpose Maybe or Some type, as much as many people would have liked us to do so. Our intention was to provide a limited mechanism for library method return types where there needed to be a clear way to represent "no result", and using null for such was overwhelmingly likely to cause errors.

For example, you probably should never use it for something that returns an array of results, or a list of results; instead return an empty array or list. You should almost never use it as a field of something or a method parameter.

In the original example posted, Optional<Y> is used as a method parameter so this is against Java best practices. Besides, Maybe is idiomatic in RxJava.

Assuming you have something like the following:

class X
class Y
data class DataContent constructor(val listOfX: List<X>, val y: Y)

You could write a function like this that would seem to fit your use case:

fun zipToDataContent(maybeListOfX: Maybe<List<X>>, maybeY: Maybe<Y>): Maybe<DataContent> =
        Maybe.zip<List<X>, Y, DataContent>(
                maybeListOfX,
                maybeY,
                BiFunction { listOfX, y -> DataContent(listOfX, y) })

Tests:

@Test
fun testZipToDataContentWithRealY() {
    val x = X()
    val y = Y()

    val maybeListOfX = Maybe.just(listOf(x))
    val maybeY = Maybe.just(y)

    zipToDataContent(maybeListOfX, maybeY).test()
            .assertOf {
                Maybe.just(DataContent(listOf(x), y))
            }
}

@Test
fun testZipToDataContentWithEmptyY() {
    val x = X()

    val maybeListOfX = Maybe.just(listOf(x))
    val maybeY = Maybe.empty<Y>()

    zipToDataContent(maybeListOfX, maybeY).test()
            .assertOf {
                Maybe.empty<DataContent>()
            }
}

One reason is that conceptually, firstName, middleName, and lastName are logically one argument, not three. They're all parts of a bigger whole, and one can imagine that they're almost always passed together. In functional languages they'd likely be passed as a tuple or record; Java lacks those, so they'd probably be aggregated into a Name class. Note that if you needed to compose functions that take and return full names, you wouldn't be able to without aggregating them - you can only return one value, after all.

Maybe it just doesn't come up very often that a value is optional and also not part of a bigger whole. If the function requires a certain value to do its work, then that function shouldn't be accepting an Optional. If you need to chain operations that might not return a value, aborting with Nothing if any function along the way fails, you can chain calls to flatMap, and if you want to fail with an exception you can use get() at any step of the way or at the end of the chain.

If a value is truly optional and a function does two different things based on its presence or absence, that's a code smell unless the function is a wrapper of two smaller functions that do one thing each, and that particular combination of decisions is very common.

I don't think it's so much that it's wrong as it is a relatively uncommon use case.