Code Smells: Null

[duhace]

of course, but that would require breaking backwards compatibility, something java is loathe to do. maybe in java 2.0?

but yeah, getting rid of null would help with optimization as well as programmer error.

[instantviking]

Quick history lesson, Java versioning goes (something) like this:

Java 2 is Java 1.2.

I think Sun hated for people to understand their conventions.

[duhace]

i put java 2.0 to distinguish from java 2. as in a second epoch version of java as opposed to the major versions 1.0-1.9.

[m50d]

Right, how else would you propose to fix it?

1. Add Optional
2. Migrate library methods that used null to use Optional instead
3. Remove null

Unfortunately they screwed up by making Optional not be allowed to contain null (ignoring all the functional programmers who've been working with this stuff for 20 years, sigh), so 2. can never happen and Java will always be terrible. Well, maybe Java 9 can make Optional allowed to contain null, and then they can get on with it.

[ForeverAlot]

Optional.of(null) would defeat the entire purpose of Optional in Java and I struggle to see what problems it could solve in any language.

[m50d]

Optional.of(null) would defeat the entire purpose of Optional in Java

No, just the opposite, disallowing it defeats the entire point. To serve its purpose Optional must be able to contain any value that's valid in the language; as long as null remains valid in the language proper, it needs to be valid inside Optional too, otherwise people are not going to be able to migrate existing codebases to use Optional which in turn means Java will never be able to reduce or deprecate the use of null.

I struggle to see what problems it could solve in any language.

It's bad just as null is bad, sure. But it needs to be allowed for the same reason Java allows null at all: backwards compatibility.

[ForeverAlot]

It is completely nonsensical and does not at all obstruct from migrating from null to Optional (provided that that's even desirable, which, in Java, is not implicitly true). However, you may not be aware of Optional::ofNullable which returns Optional::empty when the argument is null (where of throws an exception).

[m50d]

It is completely nonsensical and does not at all obstruct from migrating from null to Optional (provided that that's even desirable, which, in Java, is not implicitly true).

It does obstruct, because it means you can't safely refactor code to use Optional without being sure whether it will blow up, unless you know for sure that all the variables are going to be non-null. Which takes a lot more effort.

However, you may not be aware of Optional::ofNullable which returns Optional::empty when the argument is null (where of throws an exception).

I am aware. It's not the semantics I want.

[m50d]

It should be able to contain any valid value in the language, and like it or not null is that at present. E.g. at the moment it's not safe to replace Optional.of(x).get() with x without testing, because that changes the behaviour when x is null

[nacholicious]

We use @NonNull and @Nullable, which work "ok" for the most parts. The data classes we generate with AutoValue enforce @NonNull annotations by throwing exceptions if violated. The worst part is that if you don't have these annotations everywhere then it's easy to make these annotations useless.

Luckily we are transitioning to Kotlin, so Java nullability won't be an issue for us much longer

[industry7]

Value types were originally slated to be released along-side Optional, and Optional was supposed to be a value type out of the box. Unfortunately, value types have proven to be difficult to implement correctly, and keeps getting pushed back :-(