Java 8's Optional is a container object used to contain not-null objects. Optional object is used to represent null with absent value. This class has various utility methods to facilitate code to handle values as ‘available’ or ‘not available’ instead of checking null values. It was introduced to avoid the boilerplate surrounding null checks in Java code. However, using Optional in method arguments is usually not recommended, and there are several reasons for this.

Avoiding Optional for Method Parameters

1. Complicates Method Signatures

Using Optional as an argument type unnecessarily complicates the method signature. It can lead to more verbose and less clear code. Generally, method parameters should be simple and direct. Method signatures are part of the API documentation and should immediately suggest what the method expects and what it performs. Adding Optional can obscure the intent of the methods which isn’t ideal in designing APIs.

2. Encourages Poor API Design

When an Optional is used in method arguments, it subtly conveys that passing null might be an acceptable practice and the method is designed to handle it. This can encourage developers to pass null, defying the very purpose of Optional to avoid null checks.

3. Increased Complexity in Method Implementation

Using Optional in method arguments forces the method implementation to handle both the presence and absence of a value. This often leads to conditional logic inside the method: checks for isPresent() followed by actions based on the result, which could have been avoided if the method contract simply prevents null values and accepts non-Optional parameters.

4. Performance Implications

Although generally minimal, there’s an overhead associated with creating Optional objects especially in performance-critical applications. Creating an Optional object for each call that involves a method taking Optional arguments contributes to unnecessary object creation.

5. Not Serializable

Optional is not serializable, hence using it in method parameters, especially in frameworks relying on serialization to transport objects across the network (like in distributed systems), can lead to issues.

6. Alternative Approaches

In cases where an argument may or may not be required, consider using method overloading or different methods altogether. Alternatively, clearly document that the parameter can be null, or use assertions to enforce non-null values.

Practical Example

Consider a method that loads user details from a database. There are two ways to handle an optional argument for user ID — using Optional and not using it.

1. Using Optional:

    public User loadUser(Optional<String> userId) {
        return userId.isPresent() ? database.fetchUser(userId.get()) : User.GUEST;
    }

1. Without using Optional:

1    public User loadUser(String userId) {
2        if (userId == null) {
3            return User.GUEST;
4        }
5        return database.fetchUser(userId);
6    }

The method without Optional is straightforward and avoids unnecessary complexity. It also signals non-acceptance of null values clearly through its API.

Summary Table

Conclusion

While Optional presents a methodological way of dealing with nullability in Java, its use as a method parameter should be avoided. It's better suited for return types where it admirably communicates the absence or presence of a return value without resorting to nulls. For method arguments, clear API design, proper documentation, and method overloading or default methods should be preferred to handle optional values effectively.