ChatGPT解决这个技术问题 Extra ChatGPT

Should Java 8 getters return optional type?

Optional type introduced in Java 8 is a new thing for many developers.

Is a getter method returning Optional<Foo> type in place of the classic Foo a good practice? Assume that the value can be null.

Although this is likely to attract opinionated answers, it is a good question. I'm looking forward to an answer with real facts on the subject.
The question is whether the nullablitity is unavoidable. A component may have a property which is allowed to be null, but still, the programmer using that component might decide to strictly keep that property non-null. So the programmer shouldn’t have to deal with Optional then. Or, in other words, does null really represent the absence of a value like with the result of a search (where Optional is appropriate) or is null just one member of the set of possible values.
See also the discussion on @NotNull annotations: stackoverflow.com/q/4963300/873282

B
Brian Goetz

Of course, people will do what they want. But we did have a clear intention when adding this feature, and it was not to be a general purpose Maybe 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.

I think routinely using it as a return value for getters would definitely be over-use.

There's nothing wrong with Optional that it should be avoided, it's just not what many people wish it were, and accordingly we were fairly concerned about the risk of zealous over-use.

(Public service announcement: NEVER call Optional.get unless you can prove it will never be null; instead use one of the safe methods like orElse or ifPresent. In retrospect, we should have called get something like getOrElseThrowNoSuchElementException or something that made it far clearer that this was a highly dangerous method that undermined the whole purpose of Optional in the first place. Lesson learned. (UPDATE: Java 10 has Optional.orElseThrow(), which is semantically equivalent to get(), but whose name is more appropriate.))


(Regarding last part) …and when we are confident, that the value is never null we might use orElseThrow(AssertionError::new), ahem or orElseThrow(NullPointerException::new)
What would you have done differently if your intention had been to introduce a general-purpose Maybe or Some type? Is there a way in which Optional doesn't fit the bill for one, or is it just that introducing Optionals all over a new API would make it non-Java-ish?
By "general-purpose type", I meant building it into the language's type system, rather than providing a library class that approximates it. (Some languages have types for T? (T or null) and T! (non-nullable T)) Optional is just a class; we can't make implicit conversions between Foo and Optional as we could have with language support.
I've wondered for a while why the emphasis in the Java world was on Optional, and not better static analysis. Optional does have some advantages, but the huge advantage that null has is backwards compatibility; Map::get returns a nullable V, not an Optional<V>, and that's never going to change. It could have easily been annotated @Nullable, though. Now we have two ways to express lack-of-value, plus less incentive to really get static analysis happening, which seems like a worse position to be in.
I had no idea that using it as a return value for a property was not what y'all intended until I read this answer here on StackOverflow. In fact, I was lead to believe that it was exactly what y'all intended after reading this article on Oracle's website: oracle.com/technetwork/articles/java/… Thank you for clarifying
C
Corey

After doing a bit of research of my own, I've come across a number of things that might suggest when this is appropriate. The most authoritative being the following quote from an Oracle article:

"It is important to note that the intention of the Optional class is not to replace every single null reference. Instead, its purpose is to help design more-comprehensible APIs so that by just reading the signature of a method, you can tell whether you can expect an optional value. This forces you to actively unwrap an Optional to deal with the absence of a value." - Tired of Null Pointer Exceptions? Consider Using Java SE 8's Optional!

I also found this excerpt from Java 8 Optional: How to use it

"Optional is not meant to be used in these contexts, as it won't buy us anything: in the domain model layer (not serializable) in DTOs (same reason) in input parameters of methods in constructor parameters"

Which also seems to raise some valid points.

I wasn't able to find any negative connotations or red flags to suggest that Optional should be avoided. I think the general idea is, if it's helpful or improves the usability of your API, use it.


stackoverflow.com/questions/25693309 - it seems Jackson supports it already, so "not serializable" no longer passes as a valid reason :)
I suggest having your answer address why using Optional in input parameters of methods (more specifically constructors) "won't buy us anything". dolszewski.com/java/java-8-optional-use-cases contains a nice explanation.
I have found that currying optional results which need to be transformed into other APIs requires an Optional parameter. The result is a fairly comprehensible API. See stackoverflow.com/a/31923105/105870
The link is broken. Could you please update the answer?
The trouble is, it often doesn't improve the API, despite the best intentions of the developer. I have been collection examples of bad usages of Optional, all taken from production code, which you can check out.
C
Claas Wilke

I'd say in general its a good idea to use the optional type for return values that can be nullable. However, w.r.t. to frameworks I assume that replacing classical getters with optional types will cause a lot of trouble when working with frameworks (e.g., Hibernate) that rely on coding conventions for getters and setters.


This advice is exactly the sort of thing I meant by "we are concerned about the risk of zealous overuse" in stackoverflow.com/a/26328555/3553087.
M
MiguelMunoz

The reason Optional was added to Java is because this:

return Arrays.asList(enclosingInfo.getEnclosingClass().getDeclaredMethods())
    .stream()
    .filter(m -> Objects.equals(m.getName(), enclosingInfo.getName())
    .filter(m ->  Arrays.equals(m.getParameterTypes(), parameterClasses))
    .filter(m -> Objects.equals(m.getReturnType(), returnType))
    .findFirst()
    .getOrThrow(() -> new InternalError(...));

is cleaner than this:

Method matching =
    Arrays.asList(enclosingInfo.getEnclosingClass().getDeclaredMethods())
    .stream()
    .filter(m -> Objects.equals(m.getName(), enclosingInfo.getName())
    .filter(m ->  Arrays.equals(m.getParameterTypes(), parameterClasses))
    .filter(m -> Objects.equals(m.getReturnType(), returnType))
    .getFirst();
if (matching == null)
  throw new InternalError("Enclosing method not found");
return matching;

My point is that Optional was written to support functional programming, which was added to Java at the same time. (The example comes courtesy of a blog by Brian Goetz. A better example might use the orElse() method, since this code will throw an exception anyway, but you get the picture.)

But now, people are using Optional for a very different reason. They're using it to address a flaw in the language design. The flaw is this: There's no way to specify which of an API's parameters and return values are allowed to be null. It may be mentioned in the javadocs, but most developers don't even write javadocs for their code, and not many will check the javadocs as they write. So this leads to a lot of code that always checks for null values before using them, even though they often can't possibly be null because they were already validated repeatedly nine or ten times up the call stack.

I think there was a real thirst to solve this flaw, because so many people who saw the new Optional class assumed its purpose was to add clarity to APIs. Which is why people ask questions like "should getters return Optionals?" No, they probably shouldn't, unless you expect the getter to be used in functional programming, which is very unlikely. In fact, if you look at where Optional is used in the Java API, it's mainly in the Stream classes, which are the core of functional programming. (I haven't checked very thoroughly, but the Stream classes might be the only place they're used.)

If you do plan to use a getter in a bit of functional code, it might be a good idea to have a standard getter and a second one that returns Optional.

Oh, and if you need your class to be serializable, you should absolutely not use Optional.

Optionals are a very bad solution to the API flaw because a) they're very verbose, and b) They were never intended to solve that problem in the first place.

A much better solution to the API flaw is the Nullness Checker. This is an annotation processor that lets you specify which parameters and return values are allowed to be null by annotating them with @Nullable. This way, the compiler can scan the code and figure out if a value that can actually be null is being passed to a value where null is not allowed. By default, it assumes nothing is allowed to be null unless it's annotated so. This way, you don't have to worry about null values. Passing a null value to a parameter will result in a compiler error. Testing an object for null that can't be null produces a compiler warning. The effect of this is to change NullPointerException from a runtime error to a compile-time error.

This changes everything.

As for your getters, don't use Optional. And try to design your classes so none of the members can possibly be null. And maybe try adding the Nullness Checker to your project and declaring your getters and setter parameters @Nullable if they need it. I've only done this with new projects. It probably produces a lot of warnings in existing projects written with lots of superfluous tests for null, so it might be tough to retrofit. But it will also catch a lot of bugs. I love it. My code is much cleaner and more reliable because of it.

(There is also a new language that addresses this. Kotlin, which compiles to Java byte code, allows you to specify if an object may be null when you declare it. It's a cleaner approach.)

Addendum to Original Post (version 2)

After giving it a lot of thought, I have reluctantly come to the conclusion that it's acceptable to return Optional on one condition: That the value retrieved might actually be null. I have seen a lot of code where people routinely return Optional from getters that can't possibly return null. I see this as a very bad coding practice that only adds complexity to the code, which makes bugs more likely. But when the returned value might actually be null, go ahead and wrap it inside an Optional.

Keep in mind that methods that are designed for functional programming, and that require a function reference, will (and should) be written in two forms, one of which uses Optional. For example, Optional.map() and Optional.flatMap() both take function references. The first takes a reference to an ordinary getter, and the second takes one that returns Optional. So you're not doing anyone a favor by return an Optional where the value can't be null.

Having said all that, I still see the approach used by the Nullness Checker is the best way to deal with nulls, since they turn NullPointerExceptions from runtime bugs to compile time errors.


This answer seems most appropriate to me. Optional was only added in java 8 when streams were added. And only stream functions return optional as far as I have seen.
I think this is one of the best answer. People know what is Optional and how it works. But most confusing part is/was where to use it and how to use it. by reading this it clears a lot of doubts.
M
Mark

If you are using modern serializers and other frameworks that understand Optional then I have found these guidelines work well when writing Entity beans and domain layers:

If the serialization layer (usually a DB) allows a null value for a cell in column BAR in table FOO, then the getter Foo.getBar() can return Optional indicating to the developer that this value may reasonably be expected to be null and they should handle this. If the DB guarantees the value will not be null then the getter should not wrap this in an Optional. Foo.bar should be private and not be Optional. There's really no reason for it to be Optional if it is private. The setter Foo.setBar(String bar) should take the type of bar and not Optional. If it's OK to use a null argument then state this in the JavaDoc comment. If it's not OK to use null an IllegalArgumentException or some appropriate business logic is, IMHO, more appropriate. Constructors don't need Optional arguments (for reasons similar to point 3). Generally I only include arguments in the constructor that must be non-null in the serialization database.

To make the above more efficient, you might want to edit your IDE templates for generating getters and corresponding templates for toString(), equals(Obj o) etc. or use fields directly for those (most IDE generators already deal with nulls).


Using Lombok, I think is a good idea to have Optional private fields with default empty Optional value and with generated setters and getters...
But Lombok's developers disagree :) stackoverflow.com/a/31674917
In addition to 4: Different static factory methods e.g. Foo.withBar(...) and Foo.withoutBar(...) could also be helpful if depending on a bar being present or not there is different validation logic. But then you could also think of making it two subclasses or two distinct classes implementing the same interface.
s
soc

You have to keep in mind that the often-cited advice came from people who had little experience outside Java, with option types, or with functional programming.

So take it with a grain of salt. Instead, let's look at it from the "good practice" perspective:

Good practice not only means asking "how do we write new code?", but also "what happens to existing code?".

In the case of Optional, my environment found a good and easy to follow answer:

Optional is mandatory to indicate optional values in records: record Pet(String name, Optional breed, Optional dateOfBirth)

This means that existing code is good as-is, but code that makes use of record (that is, "new code") causes widespread adoption of Optional around it.

The result has been a complete success in terms of readability and reliability. Just stop using null.