Shouldn't Optional be Serializable?
Brian Goetz
brian.goetz at oracle.com
Sat Sep 28 00:26:52 PDT 2013
> It sounds like this should have been named something else entirely then,
> not Optional.
Perhaps. But we're not going to consume infinite time (and every experience we've had so far with Optional suggests that it truly is unbounded) correcting this mistake. Anyway, I won't comment further on Optional because there's little value in continuing the discussion. Just one correction:
> I buy this argument if there's some
> non-negligible cost to adding a feature (perf loss, code maintenance, back
> compat issues, complexity, etc) but that's not the case here.
You would be incorrect. 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.
(You can always argue "but this case is different", and it might be, but that still would presuppose that we think its a good idea.)
More information about the jdk8-dev
mailing list