valhalla-dev Digest, Vol 8, Issue 14

[Nicolai Parlog]

 Hi Thomas.

> 1) Serialization preserving identity aliases
I totally agree with everything you write. But we were not discussing
serialization of value types in Java X but of value-based classes in
Java 8. And here the fact of the matter is that serialization makes
guarantees which might not be upheld in the future, which is why such
uses must be prevented.

> 2) Equals/ Hash on composites
I like your rules A, B, C -> D a lot. I actually came up with pretty
much the same set (sure I can say that now) when I created examples
for this whole state thing.

Now I wonder whether this would be a generally advisable way to deal
with this scenario. As far as I see it, (A, B, C) could be considered
the gate into the value's state. Everything that passes is game for
equals/hashCode.

 so long ... Nicolai



On 16.02.2015 04:57, Thomas W wrote:
> 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.
>> 
> 

-- 

PGP Key:
    http://keys.gnupg.net/pks/lookup?op=vindex&search=0xCA3BAD2E9CCCD509

Web:
    http://codefx.org
        a blog about software development
    http://do-foss.de
        Free and Open Source Software for the City of Dortmund

Twitter:
    https://twitter.com/nipafx