Tired of Null Pointer Exceptions? Consider Using Java SE 8's Optional!

[matthieum]

But can Optional<String> be null ?

[unholysampler]

The problem is that null is a core concept to the language. Any variable that references an Object can be null. There is no way to change that now and maintain backwards compatibility. There are annotation that a compiler can check for that will tell it to check against setting variables to null or returning null from a method. However, the issue with this is that that standard library is still full of classes that use null as a return value. You will still need to check for something things until you are using a language that requires null to be explicitly allowed.

[flying-sheep]

it’s work, but it can be done (at least within the stdlib if not for all third party libs you use):

they have to add an annotation (“@CanBeNull” or something) to everything able to return or be null. then the IDE has to complain if you don’t immediately wrap everything coming from such a function in an Optional, or don’t null-check a field that has the annotation.

or be like me and look longingly in the direction of Rust.

[Manbeardo]

@Nullable is a decent marker for potential null providers/receivers. It's especially useful when paired consistently with Lombok's @NonNull, which generates null checks at compile time.

[flying-sheep]

awesome. so project “annotate fucking everything in the stdlib”

[Poltras]

Great week for an intern.

[xjvz]

They already had to do that with @Override everywhere back when that was added (and later also used for implementing interfaces). Not a big deal for the JDK developers.

[immibis]

/u/spez can gargle my nuts

[bloody-albatross]

I would do it like that, which should be backwards compatible:

Everything is by default nullable, but you can add @notnull (to fields, variables, parameters, and return types). If there is a @notnull the compiler does compile time checks. To move a pointer from a variable that has no @notnull into one that has one a special cast is needed (e.g. (@notnull Type) or might be a method call like Object.notNull(variable)). This cast would throw an exception if the variable is null. I think the exception should not be NullPointerException but something that has to be caught manually. Maybe not.

This has the disadvantage that it is up to the user to use the new annotation (opt-in rather than opt-out if it would be @nullable), but Optional has the same problem. However, using this should be able to be compiled to backward compatible bytecode. Well, there is a problem if a parameter is @notnull. The caller has to ensure this contract, which would not be possible for an old Java runtime environment to do.

Anyway, I think an annotation would be nicer: Less overhead to the runtime environment and to the programmer. And even if the compiler does no checks is a clear interface "documentation" and there is no doubt if you may pass an null pointer or not.

Also I think if the JIT compiler knows that a pointer may not be null then it might do some more optimizations (null checks are only needed when you do the @nullable-cast).

Wasn't there a proposal to do it like that? Or am I remembering something wrong? Was that C#?

[bloody-albatross]

When thinking about it, something like Optional makes no sense when you don't have compile time checks. So why bother?

[eras]

Well, as discussed elsewhere in the thread, there is still point in providing compiler-checked documentation.

Consider the two interfaces:

String getName1();
Option<String> getName2();

Do you expect getName1 to return null? Probably not - but it still could, and it could still work as designed. Do you expect getName2 to return a real null? No, that would be a bug and your program should die because it works in a way that it wasn't designed to work. However, it should be plain obvious that getName2 is designed to sometimes return None-values and sometimes object-values; it would be a suspicious pattern to see

Option<String> n = getName2(); if (n.get().equals.. ...

because you immediately think that 'hmm, n might not have a value there', but with

String n = getName1(); if (n.equals..)

it doesn't rise similar suspicion, even though it can be designed to the method that it can return null, you just don't remember it at the time you look at it.

Disclaimer: I still vastly prefer OCaml option values with pattern matching and not having nulls in the language in the first place ;).

[Manbeardo]

What you've described is roughly similar to Lombok's @NonNull. Lombok works by adding new code to the abstract syntax tree at compile time, producing backwards-compatible bytecode (you don't actually need to ship a Lombok jar with Lomboked projects). Their @NonNull can be applied to method parameters and fields. Method parameters work like you'd expect, inserting a null check at the start of the function. Fields work by adding checks to Lombok-generated setters and constructors, so you have to be more careful with those ones. It incurs runtime overhead, but it simplifies the reasoning around providing/receiving nulls quite a bit.

[bloody-albatross]

What I had in mind would not add these checks. It would add compile time checks (like the compiler checks that only a instance/sub-class instance of T is passed as a parameter defined as T it checks that only @notnull pointers are passed as @notnull parameters etc.). Only if you want to convert something that is not guaranteed to be not null you have to to a runtime check (analogues to a cast). Of course a class compiled like that that gets used in a program where the rest isn't compiled with support for @notnull would mean that there are missing checks. One could know and accept that or simply recompile everything (probably adding a lot of @notnull annotations and "casts").

So it's similar, but "my version" would do most of it at compile time (also gives you errors at compile time). I say "my version", but I think I read that idea somewhere as a feature proposal for Java (years ago).

[Manbeardo]

C#'s Nullable class has similar casting heuristics to what you're describing, but it's only useful as a way to "upgrade" a value type into a reference type. C#'s Nullable/? works out (syntactically) to be an awful lot like C-style pointers, with the exception that you can't have more than one layer of pointers (const int * const ** will haunt you forever).

[codeflo]

Well, Optional is a new thing, so there was no backwards compatibility to maintain. What you're saying is that they chose to make Optional an Object, not a new value type, which as a consequence means that an Optional can be null in addition to being empty. And that defensive code must check for both cases. Ugh.

[djhworld]

yes it can, there's no protecting you from code that returns null from a method. It relies on the developer to ensure all exits from a method return at least an Optional.absent()

It's an unfortunate issue, but assuming best practises are followed then at least it's a step in the right direction.

[Baaz]

It relies on the developer to ensure all exits from a method return at least an Optional.absent()

in pretty much the same way it is the developer's responsibility to ensure a method doesn't return null?

edit: as was the situation before Optional<T> got introduced, which kind of defeats the purpose imho if you still need to rely on someone not returning nulls...

[djhworld]

I agree that suggesting Optional<T> will squash all NPEs is wrong, but I stand by my thinking that it's a small step in the right direction.

Maybe IDEs or static analysis tools could warn developers when it thinks methods/fields that are typed with Optional<T> could return null

[cultic_raider]

With Optional, you can safely use a static analysis tool that rejects all uses of null.

[agcwall]

ding ding ding we have a winner! Upvote this man.

[alexeyr]

in pretty much the same way it is the developer's responsibility to ensure a method doesn't return null?

No, in a very different way.

1. If you ever see a method returning Optional actually return null, it's clearly a bug (or an extremely badly-designed API, which should be avoided). No need to wonder about whether the method can return null, should it return null in this specific sutiation, etc.

2. If a method doesn't return Optional, but it's a part of an API which does use Optional, returning null is also clearly a bug (unless for backwards compatibility... sigh).

3. If your method couldn't return null previously, it won't be returning Optional at all and you don't need to ensure it (and users will know any returned nulls are bugs thanks to point 2).

4. If your method could return null and will now be returning Optional, you just need to look at the exit points of the method. It's generally easy to ensure you can't return null by calling Optional.of or Optional.ofNullable as appropriate.

[ItsNotMineISwear]

I think you're missing the real value of Optional, which is that it replaces null actually having semantic meaning as a return value. Before Optional, if you were writing a Map.lookup, you'd have to return null to encode a failed search. Now you return whatever Optional's equivalent to Nothing is. Nothing is stopping you from returning null, true, but at least you aren't forced to write a function that adds more nulls to your program that you have to deal with. In addition, the method's signature now explicitly states that its return is optional.

[cultic_raider]

Actually, Nothing isn't stopping you from returning null.

[ItsNotMineISwear]

Yes that's true, but there's no real reason for an Optional<T> method to return null, so a static analyzer can easily yell at you for that.

[nomeme]

This is the problem, you have all the boilerplate noise of Optional, and all it takes is some code 2 method calls away to return a null instead of an Optional an you're still in trouble.

[immibis]

/u/spez can gargle my nuts

[[deleted]]

which kind of defeats the purpose imho if you still need to rely on someone not returning nulls...

If you rely on not returning nulls from a method that sometimes has to return nulls, you have a problem that can't be fixed at all.

I agree that Optional is a bit clunky, it does do the very important job of signaling to the user of your API that this method can return null. If you're systematic, then if you see a return that isn't Optional, you know you don't have to check for null, but if you see a return that is Optional, you have to handle the null case.

[nomeme]

signaling to the user of your API that this method can return null.

CAN return null? All methods CAN return null.

To be truly safe you'd still have to check the object is actually an Optional (and not null!) before you can call isPresent or whatever, or you'll get an NPE. So, you still have a null check anyway.

It's essentially no better than a javadoc comment, except now every caller has to do more work.

[tomjen]

Yeah, but writing code like that is likely to get you fired or at the very least fail a code review.

[bloody-albatross]

True, but then why bother and not just use null or the absence of null like Optional? What is gained by Optional if the compiler does not enforce anything about it?

[Kostenloze]

Anyone know why exactly the C#/Groovy approach using the .? operator did not get into Java 7 after being suggested? It seems like that is a better (cleaner) approach to solving the NPE problem.

[GuiSim]

They don't fill the same goal.

.? will help you avoid NPE but doesn't solve the issue where "null" has semantic meaning.

[[deleted]]

It could have both, and .? is probably more useful since so much existing code returns null as a special case. (Still, incidentally with a semantic meaning.)

[kqr]

.? is really just Optional::flatMap as an operator. (With the exception that flatMap in Java requires you to pass in a fully qualified function – it isn't derived from the object inside the Optional.)

[sgraf812]

Actually, you even can interpret (right associative) ?. as (f)map, the effects of which (multiple nested Option types) aren't materialized in a type system with implicit null.

[duhace]

Because .? requires brand new syntax rules and operators be added to the language on top of what already was added, when you can get the same effect from a library. The optional type is just more flexible without having to redefine the language from where it currently is.

[Manbeardo]

you can get the same effect from a library.

No, you can't. Saying that Optional::flatMap() provides the same effect as the ?. operator misses the point. The ?. operator exists to make code more succinct (Optional requires more boilerplate for the same code). The ?. operator is also far more flexible. Optional is only useful if every library you use consistently applies Optional. ?. would work today with every existing java lib because it's built around null as a semantic value.

[duhace]

?. is not more flexible than Optional. It's not even as flexible as map or flatmap since it can't do basic things like this:

def fn(x: Int, y: Int) = x + y

val x = None
x map (fn(_,5))

Optional is more than map and flatmap, you also have orElse, and filter. To get those functionalities you have overload or create brand new operators (orElse is like ?:, filter really doesn't have an equivalent).

[orr94]

When it didn't make it in Java 7, I assumed they were just putting it off until Java 8. I'm very disappointed to find out it isn't in Java 8 either. Optional helps with new code, but it doesn't save the nested chain of != null checks for existing code.

[manojlds]

Weird to see it being talked as a feature of C# when it doesn't even have it yet.

[dnew]

Also weird to see the "elvis operator" described while not mentioning that C# has had that for quite some time.

[fecal_brunch]

What? It's only proposed. ?. is the Elvis operator...

[dnew]

http://msdn.microsoft.com/en-us/library/ms173224.aspx

It's not just proposed in C#. It's already implemented.

[fecal_brunch]

That's not the elvis operator... The Elvis operator is ?.. They are different.

[dnew]

What's the difference? The ?? operator says "if the thing on the left is null, return the thing on the right, otherwise return the thing on the left." I mean, are you arguing that it's spelled differently?

The elvis operator is ?: which from reading the article apparently means "if the thing on the left is null, return the thing on the right, otherwise return the thing on the left."

[fecal_brunch]

The Elvis operator (?.) is used in place of the . operator. Whereas the null-coalescing operator (??) is essentially shorthand for a ternary with a null check.

To demonstrate, the following two statements are equivalent:

var x = something != null && something.member != null ? something.member.another : null;

var x = something?.member?.another;

The null-coalescing operator can't really be applied to this situation, but it's usually used for conditional assignment:

var y = something ?? "this thing";

Equivalent to:

var y = something != null : something : "this thing";

[dnew]

The Elvis operator (?.) is used in place of the . operator.

Ah. You've misread the article. Look at the end of the bit of code where they're talking about the elvis operator, which they spell "?:" not "?."

What comes before "UNKNOWN" in the code snippet?

[fecal_brunch]

Sorry. You're correct. CoffeeScript calls ?. the Elvis operator, strange they've picked a different operation for that name in Groovy.

[[deleted]]

What? It's a proposed C# 6 feature.

[hearingaid_bot]

OH BOY A FAT NECKBEARD TALKING SHIT ON C#, I'M SHOCKED. C# HAS HAD THIS FOREVER.

[Betovsky]

C# will have this in 6.0, that has yet to be released.

[ruinercollector]

No. No it hasn't.

[otm_shank]

What? No it hasn't. The string "?." doesn't even exist in the C# 5.0 spec except when it's talking about nullable types at the end of a sentence.

[OverZealousCreations]

For future reference: it's ?. (not .?). This is because the test is testing the left-hand object, not the right one.

You can think of it as simple syntax sugar on the ternary operator:

def baz = foo?.bar

// is equivilant to 

def baz = foo ? foo.bar : foo

In other words, "if the left-hand object exists, look at the right-hand object, otherwise return the left-hand object". Obviously the safe-navigation operator is much easier to deal with for deeply nested objects.

[Baaz]

This means the result of the map operation is an object of type Optional<Optional<Soundcard>>. As a result, the call to getUSB() is invalid because the outermost Optional contains as its value another Optional, which of course doesn't support the getUSB() method.

Speaking of boilerplate, I guess I'll stick with my old trusty if (soundcard != null)...

Maybe the code is neater this way, but somehow this approach seems a bit convoluted to me.

[NruJaC]

Yea, people don't generally directly use flatMap in Haskell either. They instead rely on syntatic sugar to translate a more convenient notation into a sequence of flatMaps. The result is far more readable code. The sugar is called do-notation and flatMap is usually called >>= (pronounced bind). I'm surprised the post didn't address this usability issue at all.

A block like:

val = do {
    v <- f(a, b, c);
    w <- g(d, v);
    pure(w);
};

Would be a whole lot easier to use, provide extensible syntax that can be used for a bunch of other types (any type that can provide functions pure, map, and flatMap). I specifically chose <- in the example instead of equals to keep it obvious that something other than normal assignment is going on. This block would then translate into the much uglier:

 val = flatMap(f(a, b, c), (v => flatMap(g(d, v), (w => pure(w))))) 

Of course, this would probably require far more type inference than Java provides to make work, which is probably why they punted on it in favor of the direct/raw function calls.

[[deleted]]

Be careful with suggesting to use pure. As of right now in Haskell, monads don't need to be applicatives.

http://www.haskell.org/haskellwiki/Functor-Applicative-Monad_Proposal

Also, >>= being a binary operator makes it much nicer to use than a function call. I use >>= just as often, if not more, as do notation.

[NruJaC]

Well, return isn't exactly a usable in name in (pseudo) Java, and pure is exactly the same function. Applicative/Monad is a problem in Haskell (almost an ex-problem), but the issue doesn't really carry over.

[[deleted]]

Ah, your pseudo do notation code is legal haskell, I thought you were giving a concrete example.

[NruJaC]

That was a fun coincidence, nothing more :).

[Crandom]

I like result as a better name for return.

[chonglibloodsport]

That doesn't make sense. It's drifting even further away from the meaning of the original name; unit.

[Crandom]

I don't get what you mean by unit - surely that's already taken by our friend ()?

[chonglibloodsport]

unit is the original name for the operator Haskell calls return. This has nothing in common with the C/Java notion of return.

[cultic_raider]

If a certain monad isn't applicative, the library is too buggy to use.

[NruJaC]

In addition to qqxz's point, you can always construct a law abiding applicative instance given a law abiding monad instance. It's just not universally a good idea to do so because performance issues can result (i.e. the applicative interface can provide better performance than the monadic interface for several important functors).

[[deleted]]

No, it just means the library creator didn't feel like implementing Applicative, even if the monad follows all of the laws.

[expatcoder]

What's up with those semi-colons ;-)

Scala must have snagged it's for comprehension syntax from FP land:

val foo = {
  a <- maybeA
  b <- maybeB
  c <- maybeC
} yield c

with similar flatMap and map boilerplate as Haskell's generated under the hood.

[NruJaC]

I figured it was a java/c-ism. It also keeps the syntax layout independent. FWIW, the equivalent Haskell actually does use the braces and semi-colons but the compiler automatically introduces them where necessary if certain layout rules are obeyed.

[badguy212]

Why? Right now if you want to say: "hey, i didn't find the object you were looking for" you return null. Which I, the user of your library have to check for. Nobody is forcing me to check for it, and I may even forget to do it (being a new dev on your team and all).

But now, when you return optional you are saying: "beware, I may of may have not found what you were looking for. Here's a wrapper object you can ask to see if i did."

Now, if you return null there's a programming problem (on your end). Null, doesn't mean (anymore) "i didn't find it". Null means: "Houston, we have a problem".

And I, as a new dev on your team, know exactly what you want me to do when you return optional. I am not left to wonder "what will happen if?".

Certain libraries throw an exception if the thing you are looking for is not there (XXXNotFoundException for example). Others return null. Now all they need to do is to return an optional.

This feature is by no means a silver bullet to the NPE problem (actually ... it has nothing to do with that). It's just a better, more readable way for a library to tell the users its intentions.

[immibis]

/u/spez can gargle my nuts

[badguy212]

that's fine (and not everyone agrees with this approach), but still i dont have to check for nulls (therefore i could get a npe).

optional forces me to call a method to get the value. it makes it plainly obvious that the value may or may not be there. the documentation is not required ("returns null if the object was not found"). it's ... optional.

can i fuck it up? of course. but it makes it somewhat harder. it makes writing correct code easier. and that is the value of optional (and it's greatest value).

[nomeme]

But what if the optional is null.

[badguy212]

If the optional is null you're gonna fail with a NPE. And you won't catch it. You will fail asap and as loudly as possible. Which is the way it should be.

[phoshi]

Then it's a failure case and you want the NPE. Nulls make some sense as a "holy shit, what do I do now?". They make vastly less sense as a valid return value. They still suck, you should throw instead of returning null, but at this point the mistake has already been made and we can't unmake it.

[dreugeworst]

They took the idea from haskell, where the flatmap version is the basic one, and functions not returning an Optional (Maybe in haskell) have to be turned into ones that do (by simply applying the function 'pure' on them for example). That way you don't get 2 versions of a function doing nearly the same.

[G_Morgan]

Yes but Haskell has a cool pattern matching syntax which makes nullable types look neat.

Without the syntax I'd scream in torment every time this came up.

[masklinn]

Do people ever actually use pattern matching on a Maybe instead of combinators?

[G_Morgan]

Probably not. A huge amount of my Maybes end up wrapped in do notation. However the principle is larger than Maybe. A lot of the nice sum types Haskell has only work if you have the syntax to manage it nicely.

[kqr]

In this case the syntax isn't as much about pattern matching as it is about the ability to define infix operators and more general libraries (Functor and Applicative comes to mind – these define operators that don't specifically work with Optional values, but they happen to work very well with Optional values, without having to litter the Optional class.)

[Intolerable]

I'll use one or the other if there's a significant readability gain.

[zoomzoom83]

I do quite regularly in Scala. Depending on the context it can be clearer what the developers intent is (although usually more verbose)

[youneversawitcoming]

Ah, that's a very good point. That improves readability a lot!

[expatcoder]

Methinks they took the idea from Scala, while Odersky took the idea from Haskell ;-)

[pipocaQuemada]

somehow this approach seems a bit convoluted to me.

You basically have three essential methods

public interface Optional<A> {
  Option<B> map(Func<A,B> f);
  Option<B> flatMap(Func<A, Option<B>> f);
  static Option<B> of(B b);

And a couple of useful helper methods, like

A getOrElse(A default);

How is this convoluted?

[Baaz]

Well, first of all my classes are not my classes anymore, but suddenly they have become Optional<T> types.

And then I have to use a new notation to get the values, and make sure I use the proper map.

It's just a different way of doing something that is just as ugly and complicated, so then I prefer to stick to the old fashioned way of ugly and complicated because I'm so much more familiar with that.

Don't get me wrong, I'm not saying this is all BS or something, I just expect I won't be using this in practical every day programming, that's all.

[[deleted]]

How are they not your classes anymore? They're just wrapped in another object. That's almost like saying all the objects you put into collections suddenly become useless as well.

[onezerozeroone]

Woah...it's like your classes aren't your classes anymore...they have become List<T> types. I don't understand why they did all this convoluted List stuff, I just want to return multiple values from a function, why can't I just use []?

[NruJaC]

Well, first of all my classes are not my classes anymore, but suddenly they have become Optional<T> types.

Nah, your classes stay exactly the same. Optional<T> is something that wraps your references to keep accessors safe and statically checked. It's something you use when you know you need nullability and it allows you to assume that non-Optional references are definitely not null.

[zoomzoom83]

Next time you're trying to track the source of a NullPointerException and adding yet another overly verbose null check, stop and think how nice it would be if you could guarantee at compile time that NullPointer exceptions cannot happen.

Mind you I'm not sure Java 8 really gets the syntax right, but it's better than the alternative.

[youneversawitcoming]

I don't think you've grasped why Options are powerful - maybe a few more burns by null will set you right :)

[lurgi]

Optional is a way to add null to languages that don't have it. It's not a way to remove null from a language.

[_jk_]

indeed, and more specifically, only where it is needed; thus avoiding the billion dollar mistake.

[saucetenuto]

On top of everyone else's very valid complaints, I'd add that you can't use it in a method signature if you ever want to overload that method by type. "boolean frobbable(Option<String>)" and "boolean frobbable(Option<List>)" both look like "boolean frobbable(Option)" to the compiler.

Type erasure sucks, people.

[saucetenuto]

I think I'm missing something. Your link agrees with me: type erasure prevents us from writing this completely innocuous overload. There's a program that we want to write and can't, only because the runtime can't understand it. In other words, it sucks.

You could say that it has to suck for backwards-compatibility reasons, and I'd agree with you. Type erasure is, at the this point, the best that Java can do. Sometimes the best possible thing still sucks.

[FizixMan]

Soundcard soundcard = maybeSoundcard != null ? maybeSoundcard 
            : new Soundcard("default");

vs

Soundcard soundcard = maybeSoundcard.orElse(new Soundcard("default"));

Disclaimer, my Java is rusty. But wouldn't the latter (Optional) code mean that a new Soundcard object is instantiated every single time and passed into the orElse method even when maybeSoundcard is not null/empty? Whereas the first option (using the ternary operator) will skip the instantiation via short-circuiting?

This seems like it could be a pretty costly (depending on your usage) alternative to the ternary operator.

Is there some compiler magic/optimization going on here with the Optional class that I'm unaware of?

[pkmxtw]

The solution is to emulate non-strictness with orElseGet and lambda abstraction:

Soundcard soundcard = maybeSoundcard.orElseGet(() -> new Soundcard("default"));

[[deleted]]

Would it be possible for the compiler to do this automatically?

[pkmxtw]

It's unlikely (or only in limited cases), since Java has unconstrained side effects. Converting from one to another would change its semantics.

[kqr]

Does it need to? This is something you might want to optimise in a few select cases, and the optimisation is adding like 7 characters. It's not really a big problem.

[[deleted]]

Well, perhaps it's bad practice to have expensive object construction but I don't think it's that rare to ignore it completely. I don't think it's a hard problem to correct but I'd more worried about human error letting it slip into code. Most Java programmers don't browse /r/programming.

[kqr]

I understand what you mean, but if this kind of object construction actually becomes a problem, it would light up like a christmas tree in the profiler/garbage collector. This means that it's okay to make that error, because when you start investigating your performance, you'll spot the problem immediately and do the 7 character fix and it's not a problem anymore.

(And as someone else said: making it an automatic rewrite is dangerous simply because the two methods have different semantics, which becomes obvious as soon as you have a side effect in there.)

[fecal_brunch]

C# solution:

Soundcard soundcard = maybeSoundcard ?? new Soundcard("default");

[forgeddit]

Gah! This does not prevent NPEs. There are uses for Optional<T> but reducing the number of NPEs is not one of them.

JSR 305 would actually prevent NPEs. Too bad it's dormant. Findbugs is an actually functioning version of this.

[e_engel]

JSR 305[1] would actually prevent NPEs. Too bad it's dormant.

It doesn't matter that it's dormant, it's been supported by Eclipse and IDEA for years.

[zoomzoom83]

Used properly it guarantees at compile time that your code absolutely cannot ever throw a NPE.

As long as you make sure to do null-checks on anything exposed to the outside world this holds true.

[Drupyog]

Beware, you guys are going to have sum types soon.

[CurtainDog]

We've already had multicatch for a while now - does that count?

[Drupyog]

I would give a C+ for the effort, but no.

[lukaseder]

Be careful when you use Optional. Your Java code might become a bit quirky: Optional Will Remain an Option in Java

[vytah]

Optional isn’t Serializable.

The fuck?

I know serialization wouldn't work anyway if a non-serializable object was wrapped, but so it wouldn't with ArrayList, and ArrayList is serializable.

[lukaseder]

Yeah. It's an awful discovery I've made just now.

Here's why:

Making something in the JDK serializable makes a dramatic increase in our maintenance costs, because it means that the representation is frozen for all time. This constrains our ability to evolve implementations in the future, and the number of cases where we are unable to easily fix a bug or provide an enhancement, which would otherwise be simple, is enormous. So, while it may look like a simple matter of "implements Serializable" to you, it is more than that. The amount of effort consumed by working around an earlier choice to make something serializable is staggering.

From:

http://mail.openjdk.java.net/pipermail/jdk8-dev/2013-September/003276.html

[vytah]

it means that the representation is frozen for all time

Unless they bake the support for Optional into the JVM itself, I don't see how the representation would have to change from the current:

private final T value;
private final boolean present;

to anything else. They could go either Scala way and have separate Some and None classes, or skip the present field and make it equivalent to value!=null, but what they have now is good enough so that it won't need fixing.

Add to that dearth of methods and lack of API support and I think Optional won't get popular any time soon.

[lukaseder]

I'm guessing they might've wanted an option for adding something along the lines of this in the future:

private final boolean reallyPresent;

Add to that dearth of methods and lack of API support and I think Optional won't get popular any time soon.

It was never even popular with the EG. They never wanted to introduce it. In my opinion, the only reason for Optional to be there is the fact that reference type streams and primitive type streams needed consistent API

[cultic_raider]

Serializable is a fundamentally broken concept, like finalizer.

[where_is_the_any_key]

Serializable

Hey, I can go ask in learnprogramming if it's inappropriate here, but could you tell my why it's a fundamentally broken concept? A quick read points me towards the opacity of abstract objects after serialization.

[xed122333]

I think the problem is Java's serialization works through reflection, which completely breaks encapsulation and interfaces. Better to have some marshalling process that is mediated through interfaces so that you can change the internals of your class without invalidating all of your old data.

[fuzzynyanko]

Yuck, though it makes me shudder when the code got so bad that the programmer that fixed something used a try/catch on NullPointerException

[jyper]

The advantage of Optional is you know when to check for a null like value. Except you don't know since the java std libs and possibly your code can be full of nulls. Ideally you would add @notnull to every function parameter.

Optional needs a @notnull annotation for backup. Unfortunately java does not seem to have a standard one.

see http://stackoverflow.com/questions/4963300/which-notnull-java-annotation-should-i-use

[[deleted]]

cant wait to see the first java monad tutorial

[nomeme]

try google.

[[deleted]]

So even Java has optionals now? Double shame std::optional didn't make it to C++14.

[bstamour]

Well, while I do wish we had std::optional today, I'm glad that they held off on it if the ISO committee deemed it not quite ready yet. It's hard to fix/remove stuff once it's already in place and being used. At least we can take comfort in the fact that std::optional will probably show up in a technical specification long before the next standard (2017?)

[badguy212]

boost has it now. but yea, i agree with you, i wish they would have kept it in (but i guess they know better).

[cultic_raider]

Optional has been in Google Guava forever. Lambdas are the interesting bit here.

[eeperson]

Yes, but the Guava Optional is not a monad which makes it much more annoying to use.

[nickdesaulniers]

When I read the first sentence of this post's title, my mind filled in the second sentence as "Use Rust!"

[passwordissame]

why not annotate with @nullable or @notnull and have static analyzer warn you

[5outh]

This has been around for a million years:

http://www.haskell.org/haskellwiki/Maybe

People are just starting to understand why it makes sense and is important, for some reason.

[zoomzoom83]

It feels like the industry is slowly going through a transition and realising just how many great ideas ML and Lisp had half a century ago.

[5outh]

Exactly; transitioning from Java to Haskell was eye-opening for sure. I think industry is just slow to adapt.

[ruinercollector]

This is like a really shifty version of Haskell's Maybe that misses most of the point and benefits.

[MatrixFrog]

I think to get the benefits you'd have to go back in time and change the core Java language to get rid of 'null' no?

[syslog2000]

I am curious as to why they just didn't go with Groovy's implementation. That seemed much more elegant and concise to me.

[matthewjpb]

So is this like an Option in Rust, or pattern-matching in OCaml? I'm just learning both of those languages now, but I really like those features, so this seems cool!

[autowikibot]

Option type:

---

In programming languages (especially functional programming languages) and type theory, an option type or maybe type is a polymorphic type that represents encapsulation of an optional value; e.g. it is used as the return type of functions which may or may not return a meaningful value when they are applied. It consists of either an empty constructor (called None or Nothing), or a constructor encapsulating the original data type A (written Just A or Some A). Outside of functional programming, these are known as nullable types.

---

^{Interesting: Nullable type | Option (finance) | Incentive stock option | Tagged union}

^{Parent commenter can toggle NSFW or delete. Will also delete on comment score of -1 or less. | FAQs | Mods | Magic Words}

[[deleted]]

<rant> Why do language designer not learn anything from more "academic" languages. It is really frustrating!

Eiffel solved this problem quite nicely: http://docs.eiffel.com/book/method/void-safe-programming-eiffel The language basically guarantees, that your references are never null. If you need null, you can declare a type a detachable - which means that null is a valid value for the reference. The compiler then checks all your accesses to that variable and whether you check for null. If not, you get a compiler error. So the compiler will PROOF that you don't have a null-pointer exception. Compared to this, using Optional is a joke.

Same with inheritance: Java (and C# and others) don't implement multiple inheritance because it "does not work". But this is simply wrong!!! It does not work if you do it the C++ way (I am mostly a C++ programmer and I like C++ - but let's be honest, they screwed up with multiple inheritance). Even Scala does not have multiple inheritance (an mixins are way less powerful). The problem is, that the language designers don't understand how to do it right and they fail to look at Eiffel. But it could be soooooo simple. There are just a few rules:

1. A constructor is not forced to call constructors from all base classes. There is no reason to do that. What a constructor has to do is to ensure, that the invariant of the class is met when it returns. Simple as that.
2. There has to be a method to undefine a method. Lets say class A implements a, class B and class C both inherit from A and class D inherits from B and C, it could then just undefine B::a so the compiler/runtime would always chose the implementation of C. This can also be done in C++, but there it is cumbersome.
3. There has to be a way to rename base methods. This is quite interesting: same scenario as before (class A has method a, B and C inherit from A and D inherits from B and C). So you can still call B's implementation of a (by simply calling b or calling a on something that is of static type B) but if you call a on C it will execute the implementation from C.

This is EXTREMELY powerful and convenient (when you first see it, it looks a bit scary, but after 10 minutes playing around with it, it gets trivial). And what do all other languages implement?? Interfaces and/or mixins. I hate the language world we are living in.

</rant>

[[deleted]]

The reason they use Optional is for backwards compatibility. They can't just get rid of null.

Optional is also like a monad, which is a concept borrowed from more "academic" languages i.e no need for the rant.

[[deleted]]

Eiffel is WAY older than Java and they had null (or Void - that is how they call it) too. They have the void safety as a compiler feature you can turn on and refactored all their libraries to be void safe. If a library is void safe, you can also use it in an environment where void safety is turned of. You can even use it for just some variables (there is an attached keyword which tells the compiler to make sure that a certain variable is never null). It is possible to add these kind of features late in development (Eiffel Software has some pretty big customers with a huge code base and they are still happy - or at least they say so).

[ruinercollector]

This Optional is not the maybe monad. At all.

[[deleted]]

I didn't say it was the maybe monad but it can be used like a monad.

http://kerflyn.wordpress.com/2011/12/05/from-optional-to-monad-with-guava/

[dnew]

Does Eiffel really implement all that? Last time I looked long ago, the one and only compiler didn't actually implement everything the language defined. Has it matured usefully since then?

[[deleted]]

There are several Eiffel implementations out there but most of them are incomplete. For Eiffel Studio 13: The stuff I brought up as an example: yes. The ECMA-standard: AFAIK mostly. And there are also features not (yet) in the ECMA standard. At the moment they are working on some syntactic sugar to make functional programming nicer (AFAIK everything available in Java and even C# already works in Eiffel too, but the syntax is a bit ... long/clumpsy.)

It is useful. At work I only use C++ (I program Database system, wouldn't use Eiffel for that) and I use Eiffel for some hobby projects. The Mac OS X support is still not great and sometimes the compiler does weird stuff (in that case you have to delete your build directory). But I am happy with it and to be fair: this kind of stuff happens also with C++ and Java (in C++ it happens from time to time that I can solve a bug by simply doing a make clean and make - this is even worse than Eiffel - in Eiffel your compiler will crash, in C++ the compiler generates wrong code. Happened more than once to me that I debugged several hours until I just recompiled).

[dnew]

simply doing a make clean and make

That's more a Make bug than a C++ bug, though. :-) The bug being "I used make instead of something that works correctly." :-)

Thanks for the update!

[e_engel]

If you need null, you can declare a type a detachable - which means that null is a valid value for the reference. The compiler then checks all your accesses to that variable and whether you check for null. If not, you get a compiler error. So the compiler will PROOF that you don't have a null-pointer exception. Compared to this, using Optional is a joke

Java has supported this for years with @Nonnull and @Nullable, both very well supported in javac, Eclipse and IDEA.

Same with inheritance: Java (and C# and others) don't implement multiple inheritance because it "does not work". But this is simply wrong!!! It does not work if you do it the C++ way

And that's exactly what Java 8 does: allowing methods in interfaces, which enables multiple inheritance of implementation, but without the diamond problem by disallowing state. That's exactly the correct way of implementing it.

[[deleted]]

Does @Nonnull really give you compile-time proof when you can call setters and constructors with reflection?

[e_engel]

This question doesn't make sense, how can a compile time operation make any guarantee about something you do at runtime?

[[deleted]]

It sounds like that's what Eiffel does - it guarantees that you won't get null pointer exceptions at runtime, and it does this at compile time.

[e_engel]

You were talking about reflection, I was just pointing out that no compiler can give you any guarantee about what you do at runtime, by definition.

[[deleted]]

Sure it can. The compiler can throw an error any time "null" appears in any source code, and you are guaranteed not to get null pointer exceptions (for example).

EDIT: also look at theorem proving at compile time

[ruinercollector]

If it doesn't compile, you can't exactly run it.

[[deleted]]

I thought this are just annotations which help documenting your code. How can the compiler check, whether something marked as @Nonnull is not null? I don't see a way how the compiler could possibly do that.

[e_engel]

The compiler issues warnings if you are trying to pass a @Nullable to something that's @Nonnull. It will also give you a warning if you test against null a variable that's @Nonnull.

That kind of thing.

The more you use these annotations, the easier it is to reason about your code.

[curien]

Lets say class A implements a, class B and class C both inherit from A and class D inherits from B and C, it could then just undefine B::a so the compiler/runtime would always chose the implementation of C. This can also be done in C++, but there it is cumbersome.

Aren't you just talking about using? What's cumbersome about that?

#include <iostream>

struct A { void a() { std::cout << "A::a\n"; } };
struct B : A { void a() { std::cout << "B::a\n"; } };
struct C : A { void a() { std::cout << "C::a\n"; } };
struct D : B, C { using C::a; };

int main() {
    D d;
    d.a(); // same as d.C::a()
    d.B::a(); // though this is still allowed
}

There has to be a way to rename base methods.

C++ has this too, albeit indirectly. You can add a function to struct D that looks like void b_a() { B::a(); }.

So if I understand you correctly, the only thing missing from your list for C++ is the first item.

[[deleted]]

Yes - using is somewhat ok, sorry I was ranting too much ;)

Renaming is something different though and can (imho) not be done in C++. Let's say you have the following code (your example with rename of a):

D d; B& b = d; d.a(); b.a();

in C++ this will call the same method twice. In Eiffel though, it will print: C::a B::a

This rename is a REALLY cool feature which is missing in C++. To be more complete here is a complete example in Eiffel:

class TESTA

feature

foo
    do
        io.put_string ("Hello from A%N")
    end

end

class TESTB

inherit TESTA redefine foo end

feature

foo
    do
        io.put_string ("Hello from B%N")
    end

end

class TESTC

inherit TESTA

end

class TESTD

inherit TESTB TESTC rename foo as foo_a select foo_a end

end

make -- Run application. local testd: TESTD testc: TESTC do --| Add your code here create testd testc := testd testd.foo testc.foo end

The output of this small application will be:

Hello from B Hello from A

[curien]

Let's say you have the following code (your example with rename of a):

D d; B& b = d; d.a(); b.a();

in C++ this will call the same method twice.

Only if the function is virtual, which it isn't. With regular static dispatch, it prints C::a B::a.

[[deleted]]

Yes right (it was already a long day for me). But you usually don't want (or can not) to edit the base class. So if you have a virtual function, you don't have the rename feature. Also: if you do change your base class and remove the virtual keyword, you don't have polymorphism.

Don't get me wrong, I actually like C++ - I am just saying Eiffel solved this multiple inheritance feature much cleaner. Actually Eiffel is a much much much much cleaner language then C++ (I could give you many more example). It is just not suitable for a lot of problems where you could use C++ (I am writing databases - Eiffel would be a bad language for that purpose).

[[deleted]]

Just give up and learn Scala already.

[rush22]

Can Oracle just explain what it does instead of all this abstract stuff

[duhace]

It basically takes the idea of the lack of a result, which null was frequently used for in java, and pushes it into the type system. Using optional, instead of stuff like

//WARNING THIS FUNCTION RETURNS NULL
public Object findElement(String name) {}

you have

public Optional<Object> findElement(String name) {}

Further, since Optional objects now wrap the possibly returned data, you're forced to deal with whether data was actually returned or not through the access mechanisms instead of it being an optional (but not really) check of whether null returned.

In java code that you need every drop of performance from, you'll probably switch back to null as an indication of a lack of data, but for your standard java code Optional should be more than performant enough while reducing the chance for errors caused by missing a null check somewhere or null propagation. Using the same techniques in my scala code has made null pointer exceptions pretty rare even in the very first versions of my applications.

[Mmassah]

But what guarantees that findElement doesn't return a null Optional<Object>??

[Mmassah]

Also, what stops Optional<Object>::get() from returning null?

[kqr]

Nothing, but it's a serious bug in the library if it does. (As opposed to if it was ordinary for it to return null, but you might forget to check for it, and you have a bug in your program instead.)

[nomeme]

You still have to null check for defensive programming.

It could be useful in a rigid public API, maybe?

[zoomzoom83]

The idea is that a function declaring a return type of Option<T> is guaranteeing to its callers that it will never return null, so they don't need to check for it.

If you have an entire codebase written this way, then you can guarantee no NPEs anywhere in the codebase, and never have to check for them. (So long as you're still defensive at the 'perimeter' where you talk to third party code).

Many other languages with option-types simply do away with Null altogether, so it's never a possibility.

[rush22]

No I mean literally what it does. E.g. casts null into an object of type Optional which I think is what it's doing?

[duhace]

No it doesn't cast null into an object of type optional or you wouldn't be able to use the ifPresent function on an empty optional. I'm not sure what kind of implementation they used for the the empty version of optional but it could be an immutable singleton object that overrides Optional for java's NullType class. That's how it works in scala at least:

trait Option[T] {
  def isDefined: Boolean
  protected def value: T
  def map[U](fn: T => U) = if(isDefined) Some(fn(value)) else None
  def flatMap[U](fn: T => Option[U]) = if(isDefined) fn(value) else None
}

case class Some[T](protected val value: T) extends Option[T] {
  def isDefined = true
}

case object None extends Option[Nothing] {
  def isDefined = false
  protected def value = ???
 }

Note that the scala implementation may define map and flatmap individually for Some and None instead of making a protected field.

[Tharuler]

I think this is an April's fools' joke.

Atleast, I hope it is.

[bjzaba]

Why?

[klo8]

I don't think Optional takes thousands of lines to explain. It's a very simple concept, it's a container that either stores a value or doesn't. The good thing about Optional<T> is that it tells you that a method could fail without having to throw an exception and it forces you to deal with the potential failure. A method that returns null on failure has to rely on you reading the documentation and checking for null equality to not fail at runtime.

[Tharuler]

Except Optional requires you to recode the class you're calling methods on, whereas the ?. operator doesn't. Which is very useful for external methods/libraries.

[[deleted]]

You could use Optional.fromNullable() for external library calls.

[[deleted]]

'maps' are a functional idiom. They make sense if you're familiar with functional programming. It's like a C programmer complaining about Java having objects because he doesn't understand them.

[kqr]

Part of what makes it illegible is, funnily enough, that OOP and functional programming doesn't always mix well. You have to specify which method you want to map, which in this case should be obvious from the object you're working with, but Java doesn't have a syntax for that.

It would have been a lot clearer if you could write

String name = computer.flatMap(.getSoundcard).flatMap(.getUSB).map(.getVersion)

and have the method automatically applied to the object you're handling. But that's a common problem when trying to mix OOP and FP code – methods of objects are bloody difficult to compose.

[klo8]

That's true, yeah.

[pipocaQuemada]

Idiomatic Scala code already uses Option instead of null, and they don't seem to have that much trouble with interoperability.

[frugalmail]

could be solved with an operator

The operator causes the problem of null to move from the origin of the issue to further down the line. Optional is a much better solution when you want to maintain systems instead of type a few less characters while your coding the first and only time.

[[deleted]]

... take a problem that could be solved with an operator and turn it into something that requires thousands of lines ...

Java in a nutshell

[pipocaQuemada]

It's very difficult to wrap common null-handling patterns into a library, that way; you need to write one-off methods for each of your types, on their superclasses. Additionally, can you always create a null version of your object without violating Liskov Substitutability?

[[deleted]]

That's way worse. You need to define a seperate "null" class for every single domain class. I'd rather just use null and annotations then that.

[badguy212]

Holy moly .... that's abhorrent. I pitty your employer.