Optional types are an attempt to patch the "billion dollar mistake". When you don't know if you have a value or not, you wrap it in an Optional
, which ensures that there is a value (the Optional
itself), thus avoiding null reference exceptions. Then you can query the Optional
to see if there is a real value or not.
This is all fine and good, and can cut down on some bugs. Good implementations are loaded with convenience methods which make it easy to work on the optionals.
But then, you get code like Burgers found. Which just leaves us scratching our heads:
private static final Optional<Boolean> TRUE = Optional.of(Boolean.TRUE);
private static final Optional<Boolean> FALSE = Optional.of(Boolean.FALSE);
Look, any time you're making constants for TRUE
or FALSE
, something has gone wrong, and yes, I'm including pre-1999 versions of C in this. It's especially telling when you do it in a language that already has such constants, though- at its core, these lines are saying TRUE = TRUE
. Yes, we're wrapping the whole thing in an Optional
here, which potentially is useful, but if it is useful, something else has gone wrong.
Burgers works for a large insurance company, and writes this about the code:
I was trying to track down a certain piece of code in a Spring web API application when I noticed something curious. It looked like there was a chunk of code implementing an application-specific request filter in business logic, totally ignoring the filter functions offered by the framework itself and while it was not related to the task I was working on, I followed the filter apply call to its declaration. While I cannot supply the entire custom request filter implementation, take these two static declarations as a demonstration of how awful the rest of the class is.
Ah, of course- deep down, someone saw a perfectly functional wheel and said, "I could make one of those myself!" and these lines are representative of the result.

This post originally appeared on The Daily WTF.