Optional is another nice addition, I've been creating one myself in all Java projects I've created since I first encountered it in Rust.
I think you can define the types to get around it, but that is messy and a PITA. For example, class OptionalA extends Optional<A>.
The major pain point with generics is that they don't work with primitives.
Is there a particular use case?
There's no equivalent of scala's orElse(returning a second optional if the first one is null) and since default methods while useful don't allow adding things to types you don't own you can't use an method like notation for the best you can get is static importing and wrapping a function around it). ofNullable(creating an empty Optional from a null instead of throwing) isn't the default(of which throws is). Also Optional isn't an Iterator which is disappointing since using it with a for loop can be useful if you want to avoid nested closures.
But worst of all it's like they haven't started slowly deprecating most of the standard library(anything that makes sense to pass null to or that it makes sense to return null in some cases according to the api. Option types are arguably the best solution for the null problem at least for statically typed languages but having null still be possible while having Option is arguably the worst of both worlds, in my understanding scala deals with this by almost never using Null except for java compatibility and tries to create Options as soon as possible if calling a java function that may return null.
Basically I think they need to make some sort of standard Nullable and NotNullable annotations, add it to everything in the std library, and have some sort of package annotation that tells the ides to check every call to a Nullable and bug you to wrap it in Optional.ofNullable. Then deprecate those methods with Nullables by java 10 or 11 with strong warnings for ths who call them(or possible forcing a special compiler flag/package annotation to use them).
Even not doing that they are still adding methods that return null(such as Hashtable::computeIfAbsent) instead of Optional. Why for fcks sake?
If you want code that won't compile due to @Nullable violations I think the Checker framework can give you that, or you can use an IDE that flags violations like IntelliJ and just treat any static analysis warning in that category like a compile failure for your own purposes. The nice think about nullity annotations is that the newest JVM languages like Ceylon and Kotlin are building nullity into their type systems, so if you annotate an API in this way, code written in these new languages will know automatically that the reference can be null and the compiler won't let you access it at all until you tested or asserted away the nullness. The upgrade path for Kotlin especially is looking like it could be quite strong, so I think I'll be sticking with @Nullable for now in the hope that later on we get "real" type system integration via newer languages.
public ImmutableMap<String, Long> getSessionTime(HttpServletRequest request) {
return Optional.ofNullable(request.getSession(false))
.map(s -> ImmutableMap.of("lastAccessedTime", s.getLastAccessedTime()))
.orElseThrow(IllegalStateException::new);
}
Session s;
if ((s = request.getSession(false) != null)
return ImmutableMap.of(....);
else
throw new IllegalStateException();
public ImmutableMap<String, Long> getSessionTime(HttpServletRequest request) {
return request.getSession(false)
.map(s -> ImmutableMap.of("lastAccessedTime", s.getLastAccessedTime()))
}
Of course this is a trivial example where the programmer is likely expecting null, but many times null can be returned and it is not always clear.
[1] https://code.google.com/p/guava-libraries/wiki/UsingAndAvoid...
Due to backwards compatibility concerns, no existing Java APIs that may currently return null can ever be changed to return Optionals instead, so nulls need to be dealt with regardless. Also, there's technically nothing stopping an Optional value from actually being null itself, or from developers calling Optional.get() without checking isPresent(), just like they might currently use a reference without checking for null.
I personally really wish jsr305 had been adopted in Java8, and their existing APIs retrofitted with these annotations.
http://www.oracle.com/technetwork/articles/java/java8-option... describes Optional, and compares it to how in Groovy, the safe navigation and elvis operators allow you to write code like this:
String version = computer?.getSoundcard()?.getUSB()?.getVersion() ?: "UNKNOWN";
String version = computer.flatMap(Computer::getSoundcard)
.flatMap(Soundcard::getUSB)
.map(USB::getVersion)
.orElse("UNKNOWN");
New languages like Kotlin solve this much better in my opinion by introducing nullable vs nonnullable types. While Java can unfortunately never adopt this due to backwards compatibility issues, @Nullable and @Nonnull will do most of the time, and hopefully we'll see operators like ?. and ?: in future versions of Java.
With option, you clearly declare what is safe, and what isn't, and the compiler won't let you screw up. You can decide which layer of your code handles the empty case, and lots of unnecessary ifs go away from the bytecode itself, so the app will run faster, and you know when you have to even consider the null case.
Now, doing that in Groovy is rather silly, because your language is dynamic and your types are optional, so all of this compile time safety would not provide any value anyway. Option is just the way you'd solve the problem in the strongly typed way. It's how you handle it in Scala, for instance, and how Haskell would deal with it.
As far as using flatmaps and maps to work with optionals, yes, it's a chore. I'd argue it's borderline abuse of the stream operators, as treating Option as a collection is ugly. That said, putting yourself in a situation where you chain 3 optional getters is also object design from hell, so one should avoid putting themselves in that position altogether.
In Scala, instead of flatmapping single optionals, we often getOrElse(), or use pattern matching as an extractor. Now that's a feature I would like to see Java 'steal' from the Scalas and Erlangs of the world, but I do not see that happening.
The elvis op is called the null coalescing op in other languages. [1] Groovy's promoter chose the elvis name to fit in with marketing the Groovy and G-String names.
PHP also uses the ?: symbol but other languages use different ones, e.g. C# uses ?? and Perl uses //