Optional can technically be used as a method parameter type in Java, but it is widely considered an anti-pattern because Optional was designed as a return type to signal a possibly-absent result, not as a general-purpose way to model optional inputs.
Key Points: • Using Optional<T> as a parameter forces every caller to wrap arguments, e.g. method(Optional.of(value)), which adds ceremony without real safety benefits. • Optional is not Serializable, which can cause problems if the containing object needs to be serialized. • A null-checkable parameter or method overloading communicates optionality just as clearly, without the extra wrapping and unwrapping. • Optional itself can still be null if a caller passes null instead of Optional.empty(), defeating the safety it was meant to provide. • The Java API designers explicitly recommended against Optional as a parameter or field type in Optional's own Javadoc guidance.
Example: Instead of void createUser(Optional<String> middleName), it's preferable to overload void createUser(String firstName, String lastName) and void createUser(String firstName, String middleName, String lastName), or accept a nullable String with a documented contract.
Interview Tip: A concise interview answer is:
"You can use Optional as a parameter, but I avoid it — it complicates method signatures because every caller has to wrap their argument, and Optional itself can still be null, so it doesn't fully solve the problem. I reserve Optional for return types where it clearly signals that a method might not produce a value, and use overloading or plain nullable parameters for inputs."