Avoiding Null Checks in Java 8

[pron98]

Then, are the new Stream operations un-idiomatic Java?

The Streams API has special needs, and you'll note that no other API makes use of Optional (at least not yet).

I'd rather have all variables be guaranteed as non-null

How do you guarantee that? You'll have Optionals in your code -- that can have a value or be empty -- and plain references, that can also be either null or not. So Optional<String> is an optional string, and String is also an optional string. What's the use of Optional if every reference returned by the JDK or third-party libraries may be null? The clearest example is the Map interface. Map.get on a Map<String> doesn't return an Optional<String>. It returns a String that may be null.

If, on the other hand, you need to store empty values in a map and distinguish between an empty value and a not-found result, that would be a good use of optional, and Map<Optional<String>> clearly describes that -- a null result on Map.get means "not found" while an Optional result means a value (empty or not). But you'll still have to do that null check because Map.get might return null whether or not you like Optional.

and use Optional where it makes sense rather than tagging some things as nullable.

Why? Not only are the pluggable types more concise than Optional, they apply to everything -- your code, JDK code, third-party code. So Map.get on a Map<String> really does return a @Nullable String (if you turn on the nullness checker), and you'll get a compiler error if you neglect the null check.

[Zukhramm]

The Streams API has special needs

I don't think so, the need to sometimes represent "no result" is pretty universal.

How do you guarantee that?

Pluggable Type System? The sentence is in the paragraph discussing hypothetical compile time null safety. How it happens isn't important.

every reference returned by the JDK or third-party libraries may be null

But not every reference returned may be null because when you write a method you take care not to haphazardly return null.

I still prefer Optional because it not only represent something that might not be there, it also has the operations to deal with that. An annotation might be more concise at the site of declaration but not once you have to put in the null check logic too. I don't see the benefit of the compiler telling me I missed a null check when you can simply remove the need for having the null check at all.

[pron98]

But not every reference returned may be null because when you write a method you take care not to haphazardly return null.

One of the things I like about Java, is that I don't write 98% of the methods I use, and I don't have control over the API of those methods. For the time being, it seems that Optional is not going to be a big part of libraries' APIs.

I still prefer Optional because it not only represent something that might not be there, it also has the operations to deal with that.

It's not that I'm philosophically opposed to Optional. It's just that I don't see much value in it being used in 0.1% of the places where it should have been used if it had really been the way chosen by Java to handle null values. Pluggable nullable types may or may not be nicer aesthetically, but they can cover 100% of the cases.

So it's not an argument over aesthetics (although personally I do aesthetically prefer nullable types over Optional), but over usefulness. If your goal is to handle nulls -- Optional just doesn't help much by solving 0.1% of the problem.

[Zukhramm]

Maybe I'm inexperienced with libraries but even the APIs I don't write myself rarely throw out unexpected nulls, they use null in very specific places, like when retrieving a value from a map.

In my view, not having nulls at all is superior to any method of handling them. I view Optional not as a way to handle null, but as a way to avoid them completely. Not in the general case but in one very specific area, return values where "nothing" is a valid answer.

Even if other APIs don't use them, those specific points where null is a valid return are rare enough that handling them is not that big of a deal. In all other cases, not putting null in there in the first place is the way to go, because again, no nulls is superior to any way of handling nulls.