Where should Optional be used, and where is it a mistake?

Optional was designed as a return type for methods that may legitimately have no result, so the caller cannot ignore absence. It is a poor fit for fields, constructor parameters and method arguments, and it should not wrap a collection, since an empty list already says nothing here. Calling get without checking defeats the purpose; use map, filter, orElseGet or orElseThrow with a meaningful exception.

It exists so a method signature can say this may not return anything, which a nullable return type never communicated. So repository style lookups return an Optional and the caller is forced to deal with it. Where it goes wrong is when people put it everywhere. As a field it adds an object per instance and is not serializable, which causes real problems in entities and payloads. As a parameter it just gives callers three states to think about instead of two, so I use an overload instead. And a method returning a collection returns an empty collection, never an Optional of a list, because empty already means the same thing. Style wise, if I write isPresent followed by get I have just written a null check with extra ceremony, so I chain instead: map to the thing I want, filter, then orElseThrow with a domain exception that says which id was not found. The one thing I would not do is use it as a general purpose null replacement across an existing codebase, since the mixed style is worse than either convention alone.