After working with the JDK implementation of Java 8 Optional<T> I for quite a while I came to the conclusion it contains a lot of hard to ignore deficiencies. This, of course, is my personal opinion and I would like to hear yours.

This is why I have 'issues' with JDK-Optional<T>:

- JDK-Optional<T> is not serializable for hard to follow reasons (e.g. http://mail.openjdk.java.net/pipermail/jdk8-dev/2013-September/003276.html)

- But then, Guava-Optional<T> IS serializable

- This makes migrating from Guava a real pain (effectively you can not store fields in serializable classes as Optional<T> but have to wrap / unwrap them)

- So all getters / setters / method with return values are wrapping / unwrapping like crazy (which sucks big time and cost performance)

- The JDK Optional is meant to be a return value wrapper (following the blog posts from the dev), not a full monadic type

- I wonder why not?

- In any other language with 'optionality support' I know (Swift, Scala, Haskell, etc.) Optional / Maybe / Option is highly integrated, a joy to work with and helps preventing null pointers completely

- It's considered bad style to unwrap / wrap Optional all the time, in Java it's a necessity

- Being able to monadically compose is cumbersome in jdk (it seems like the Oracle devs did not fully get grasp of the functional paradigm imho)

My personal 'solution' was writing an own 'Opt<T>' class (less than 200 lines, being fully serializable and containing all the functional goodness you would expect).

Downside is, I am not using the jdk given default impl. But hey, how many are using java.util.logging (and not slf4j, log4j2, etc.) ?

Let me know what your personal conclusions are in this topic!

Thanks a lot

Peter