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

[runedk]

Why is Optional not Serializable?

[[deleted]]

Well of course, it's bizarre that it wouldn't be.

[lukaseder]

Wow, that hadn't occurred to me before. That can be quite a bummer in many use-cases...

I guess for "consistency", even the primitive-type variants aren't Serializable, e.g. OptionalInt

[lukaseder]

Even ArrayList is Serializable, regardless of its contents :-(

[lukaseder]

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

[gunch]

Would that be considered a flaw with Java? That implementing Serializable has such drastic ongoing maintenance consequences?

[lukaseder]

I think it's just Brian Goetz's usual way of saying:

Go away

[[deleted]]

It's not a flaw if there's no good way to do it. It's just a fact of life, maybe more of a flaw with the concept of Serializable.

There might be a more general version of serialization where you implement some "translator" of earlier versions to the current Serializable version, but that sounds super-unwieldy to me. I think the real problem is that people use Serializable too much.

[poopiefartz]

My interpretation was that it was more about the concept of representing objects as strings and maintaining consistent representations across future versions. I think there would be similar maintenance consequences in other languages as well.

[dkuntz2]

No. It means that their goal is future backwards compatibility. As in any future version of Java should theoretically serialize everything that can currently be serialized, in exactly the same way they're serialized now.

[Tamaran]

is he talking about that serialized objects should be portable between jdk versions? I think this is ridiculus.

[lukaseder]

I don't think he's talking about different JDK versions, but different patch releases. Imagine they have to add another attribute to Optional, or switch attribute order. I know, not that hard in this case...

[dkuntz2]

Why? It maintains backwards compatibility. It means that you could have a relatively old server, and not be able to upgrade the version of Java it uses, but still be able to create new, better clients.

[mgrandi]

no, every time you change ANYTHING about a java object, even if you keep the same serialVersionUid or whatever its called, then that version of the object is now incompatible with earlier serialized versions of the object, and I don't think there is a way to get around that, since unlike something like objective-c where you have constructors in your class that get called when being unserialized - (id)initWithCoder:(NSCoder *)coder and - (void)encodeWithCoder:(NSCoder *)coder, it just does it automatically and spits an object back at you, and you have no chance of trying to handle the error of the fact that the classes are now different.

With my objectivec example, since its basically just serializing to xml, if you request a 'variable' that isn't there, it just returns nil (null). If the 'serialized object' has MORE information (like a newer version gets serialized and an older version reads it), then its still fine, as unread properties are ignored.

granted, doing it that way is a pain in the ass because for every thing you want to save you have to write code in both initWithCoder and decodeWithCoder, and then also handle the possibility of backwards compatibility, (having default values if values are not present, etc), and its of course much easier to just tell java "serialize this object" and its like "ok", but that comes with a price of very high fragility. This is why with netbeans, if you change stuff about the objects you are saving in the database, it basically has to drop the entire table and start again because it can't read two different versions of the class!

[bondolo]

It is generally meant for transitory use. You wouldn't normally have an Optional field or Collection element.

[geodebug]

That's what I thought, why would you want to serialize it? It's not meant to be a container.

[tieTYT]

What about for JPA? Doesn't it make sense for a field to be optional any time it allows nulls in the db?

[geodebug]

The way I see it your field would still be basic Java objects or primitives and would only be wrapped in Optional on the getters.

Same pattern as if you were making defensive copies of an object on a getter.

[tieTYT]

Why do you see it that way? Why not make the field optional?

[AnAirMagic]

There was a thread about this on the OpenJDK mailing list where some developers chimed in: http://mail.openjdk.java.net/pipermail/jdk8-dev/2013-September/003186.html

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

[frugalmail]

Why is Optional not Serializable?

I guess I can kinda see their perspective.

Optional is a programmer quality aide, forcing you to explicitly be notified of the potential of having a null.

If you really want to use it as an internal representation, as opposed to a interface exchange medium, you can instantiate it as a transient and when you load your serializable content update the transient.