Value-Based Classes - Serialization
brian.goetz at oracle.com
Sat Feb 14 20:38:00 UTC 2015
> So my question was asking why still some value-based classes *are*
I think you have to ask the authors of those classes. None of the ones
delivered by JSR-335, to my knowledge, are. Arguably, the stricture
against serializability in the value-based definition is too strict;
there is a reasonable semantics for serialization of *true* value types.
But, because serialization, as currently defined, makes promises about
object identity, and value-based classes do have an identity (albeit one
that should be ignored), the definition erred on the side of caution.
> That is rather confusing. Does the warning overrule the
> interface implementation? I'm currently implementing FindBugs rules
> for this. Should it create warnings for all serializations of
> value-based instances?
Probably not; I think the more significant error is using == to compare
value-based instances (except perhaps to null.)
>> (Still, there's one big hole that even this attempt can't plug --
>> nullity. Value types are not going to be nullable. The fact that
>> we can't proscribe value-based classes from being nullable is going
>> to create some really nasty migration compatibility constraints.)
> Damn. Please make it so that Optional becomes a value type (or box
> thereof)! All else would suck. (I guess this is no news, though.)
Yeah, this is pretty bad. On the one hand, Optional is the canonical
example of a value type. And, assigning null to an Optional is a pretty
questionable thing, given that the whole point of Optional is to make
the "present/absent" distinction more explicit. But switching Optional
to a value type would definitely be incompatible. There's an argument
we could make that this sort of incompatibility is OK, but it's going to
be pretty hard to make that same argument for value-based classes like
I haven't given up on this, but the ideas we've come up with so far in
this area aren't super-attractive.
More information about the valhalla-dev