My problem with Optional<T> is that it basically makes overloaded Java methods impossible because of erasure. I'm worried that it is going to start getting overused; the JDK developers really only intended for its use in the Streams API.

I was wondering why Optional support which I was so interested in seemed so quickly inserted/poorly thought out.

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?

Could you explain that a little bit more? I'm using to Maybe from Haskell and am curious what might be missing from Java's Optional.

Basically, because of type erasure you cannot have overloaded methods using different Optional types. So test(Optional<A> a); is the same method as test(Optional<B> b);

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>.

That doesn't seem so bad to my eye, though. In Haskell terms it just means that any overloaded operators on Optional have to respect parametricity. If you need something more specifically typed then you can just use a new name.

Is there a particular use case?

Wow that's a real pain point. Why would they even do that, is there a use case?

Backward compatibility - you could run an application that uses generics, introduced in Java 1.5, on a Java 1.4 VM. At the time that was pretty amazing. These days, with so many backward compatibility-breaking changes being introduced, it doesn't feel so great.

That was the original plan, but it never worked in my experience. The compiler as shipped required that -source 1.5 use -target 1.5. So hobbling the language this way served no benefit in the end.

Btw, type erasure is only a problem for Java because it supports runtime type information (which is incomplete, because of type erasure), and overloading (which I have no idea why the compiler can't handle). For languages like ML and Haskell, type erasure is no problem, because you can't access the types at runtime anyways.

In my opinion, no it really isn't. You can just create a method with a different name or a static constructing method if you need to overload constructors.

The major pain point with generics is that they don't work with primitives.

Because of type erasure, all Optional<T> are the same type at runtime, so Optional<Integer> can't be overloaded with Optional<Boolean>, because at runtime it will be impossible to tell which method should be caled.

I still prefer using JSR-305 annotations/tools (like Findbugs) to do static analysis. Reification should help Optional<?> become more useful, but why would you ask for run-time checking when in most cases compile-time checking identifies the problems?

Guava has a nice explanation: https://code.google.com/p/guava-libraries/wiki/UsingAndAvoid.... Essentially, it forces you to actively think about the "absent" case when programming.

For those still on pre Java 8, Google's Guava also adds Optional and other useful things like immutable collections.

And now frameworks can finally supply Optionals, since it before only lead to multiple competing implementations.

But is it really better than @Nullable?

I would say in most cases: no.

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";

With Java 8 Optionals, this instead becomes:

   String version = computer.flatMap(Computer::getSoundcard)
                            .flatMap(Soundcard::getUSB)
                            .map(USB::getVersion)
                            .orElse("UNKNOWN");

which is not only much longer and arguably uglier, but also forces developers to suddenly have to worry about applying lambdas using flatmap vs map, where conceptually you're really just dealing with method calls.

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.

While I've enjoyed the Elvis operator in Groovy, the point of optional is to make null go away altogether. In Groovy, you are never guaranteed anything isn't null, so the end result is that you will Elvis everything. While this is easier than the good old if statements, you are still paying for the penalty of a billion ifs in bytecode.

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.

> in Groovy, the safe navigation and elvis operators

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 //

[1] http://en.wikipedia.org/wiki/Null_coalescing_operator

Completely different concepts. @Nullable expresses an precondition indicating whether or not something can be null. One example of its use is by static analyzers such as Findbugs to find misuse to APIs. In contrast, Optional encapsulates the behavior when something is not present (or null) -- very similar to the Null Object pattern [1]. Used together, you can build an API that permits encapsulates the present/not present behavior and ensure that it is not passed a null reference to the Optional instance.

[1]: http://en.wikipedia.org/wiki/Null_Object_pattern

It is a pity that Qt is not mentioned in that article. AFAIK, It is the only widely-used C++ library that implements null objects consequently. Ever wondered why the Qt framework doesn't use any exceptions or C-style error codes? It is solely because of proper use of Null objects.

Given how few tools understand @PolyNull, yes. Better to have one type system rather than two.

Of course it's better than @Nullable. @Nullable-annotated code still compiles your NullPointerException-throwing code, using Optional won't.

Assuming that nobody screws up and assigns null to an Optional return result/variable instead of Optional.empty(), or calls Optional.get() without remembering to check ... in other words, it's very much like @Nullable when using a compiler that understands it, except it causes problems with overloading and reflection as noted above due to generics type erasure.

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.

I don't think @NotNull/@Nullable go away completely, but the use of optional makes dealing with nullables much easier. I think this is a much cleaner ways to deal with possible nulls:

    public ImmutableMap<String, Long> getSessionTime(HttpServletRequest request) {
      return Optional.ofNullable(request.getSession(false))
        .map(s -> ImmutableMap.of("lastAccessedTime", s.getLastAccessedTime()))
        .orElseThrow(IllegalStateException::new);
    }

If/When HttpServletRequest is updated to support Optional it can return it directly instead of the caller having to do it, and that is when Java will really see the upside.

Hmm, if I understood that code it could be written like this:

    Session s;
    if ((s = request.getSession(false) != null)
      return ImmutableMap.of(....);
    else
      throw new IllegalStateException();

Maybe I'm weird but I find the old fashioned version far easier to read than the new form.

Shifting the null checking to the type system is the biggest win. So, assuming the getSession() returned an optional:

    public ImmutableMap<String, Long> getSessionTime(HttpServletRequest request) {
      return request.getSession(false)
        .map(s -> ImmutableMap.of("lastAccessedTime", s.getLastAccessedTime()))
    }

The above would not work because the call is returning another optional. The null is forced to be dealt with instead of allowing it to lead to programmer error[1]. The construct makes the programmer either call either orElse(), orElseGet(), or orElseThrow(). The programmer could also just return the optional and let the caller deal with it.

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...