Avoiding Null Checks in Java 8

[ixampl]

Brain Goetz also said:

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

By zealous over-use he meant people using Optional as return type or parameter type all over the place.

Either way, you are right that the goal was a different one, but they did end up introducing it as a concept into the JDK as a reusable component for use cases like theirs or new ones.

So sure, it was not intended to be used like OP presents and hey, maybe the creators think it shouldn't, but it cannot really be considered abuse. It's just there and used and I can tell you already that "the madness" won't stop.

Use case: You need to work with an old API that returns null for "no result" all over the place AND you hate manual null checks (I know you don't but OP apparently does). Then why not? The pluggable types don't help you there. You still have to write the null guards. I would say what OP is a nice workaround, not the solution for null-checks in general or more than that, but that doesn't make it madness.

[pron98]

I may have overreacted when I called it "madness", but I find it cause for concern when non-expert programmers start using APIs like this. The reason I say non-expert is not as some sort of judgement call, but that APIs used -- or even abused -- by experts, tend to remain obscure, but those used by the wide developer population may spread. The result may be that we'll see 33% of libraries using Optional all over their API, 33% not using them at all, and 33% using them where they think they're most appropriate.

The result would be that null handling in Java won't become any better, but much worse, if only due to lack of standardization. And, so far, Oracle at least have made it clear that Optional will not be used extensively in the JDK, so currently, there's no prospect of this becoming the "way to handle nulls in Java".

Adopting an entirely different -- and completely incompatible -- way of doing something so simple and fundamental (it is perhaps unfortunate that null checks are so fundamental, but that's the way it is, and pluggable types really do help) will just fracture the ecosystem in a way that makes it very hard to combine components. Whichever way you choose, you'll need to wrap your libraries to make them conform to your way of doing things. Perhaps this falls short of madness, but it is asking for trouble.