valhalla-dev Digest, Vol 8, Issue 14

[Thomas W]

I don't really see such difficulty?

1) Serialization preserving identity aliases

Since values do not have a significant identity, "preserving same identity"
must be meaningless for de/serialization. It's not required, it can't be
achieved, and it doesn't mean anything for value types! I would therefore
say that guarantees as to deserialized identity for Value types just
becomes dropped/ meaningless, rather than anything that would break/
prevent serialization.

Considering that, I don't see the reason for value & value-based types to
not be serializable/ or for there to be difficulties in this area.
Value-like types should indeed logically be the types most easiest & most
able to be serialized.

2) Equals/ Hash on composites

Theoretically, a Value-like type should be fully able to compose immutable
values; StringHolder{String s} is obviously fine, once we can recognize
String as immutable. And these "child" value fields should logically be
fully usable in equals()/ hashCode(). So that part of the specification
seems slightly amiss -- are we are lacking an annotation to mark classes as
immutable/ value-like?

We could also potentially consider allowing Value-like types to compose
mutable objects, if they could be proved or designated to be all of the
following:   A) exclusively owned by the holder,  B) be encapsulated by the
holder (no exposed reference), and C) have no mutators exposed via the
holder.  Meeting all of these conditions yields -> D) an object whose value
is held, but cannot be mutated.


Regards
Thomas Whitmore



<brian.goetz at oracle.com <valhalla-dev-request at openjdk.java.net>> wrote:

> The primary tension is that serialization depends on identity to ensure
> a topology-preserving reproduction of the original object graph.  For
> example, imagine Foo is a value-based class:
>
> Foo[] arr = new Foo[2];
> arr[0] = new Foo(0);
> arr[1] = new Foo(0);
>
> Serialization promises that on deserialization of arr, elements 0 and 1
> will not be aliased.  Similarly, in:
>
> Foo[] arr = new Foo[2];
> arr[0] = new Foo(0);
> arr[1] = arr[0];
>
> Serialization promises that on deserialization of arr, elements 0 and 1
> *will* be aliased.
>
> True value types cannot -- and don't want to -- preserve these promises.
>   So serializability is one of those things that might inhibit migrating
> a value-based class to a true value type.  Hence the warning that this
> falls outside the notion of value-based.
>