valhalla-dev Digest, Vol 8, Issue 14

[Thomas W]

Hi Nicolai.

[1) Serialization preserving identity aliases]
> 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.

Thanks for your comments!  What I was trying to capture was the "logical
insight" into what a Value is, whether that value is implemented as a value
type (Java X) or a "value-like", "value-based" etc class sooner.

The "guarantees" about serialization & aliasing, may effectively be more
about being able to handle (serialize & deserialize) _reference cycles_
than about preserving aliases. Cycles crop up early on in rich data
structures, and need to be handled -- this would probably be the first
driver of the requirement for serialization to handle identity. Spec about
"aliasing" may just be a poor way of wording this.

This would lead to the suggestion that (hopefully) cycles aren't going to
be relevant in Value-based or Value-like classes, either. If we could
decide that the spec is more about handling cycles than about preserving
aliases, this might clear the path forward to some degree.

Regardless, Java should offer a clear and planned path to remove such
guarantees for Value-based types.

Value-like types (String, Integer etc) are a more difficult kettle of fish;
 we should annotate these, but there are probably limitations:
- we cannot in the case of String, get rid of local identity;   since
intern() explicitly makes string identity an optimization & an issue.
- I've seen code using String as a lock.
and OTOH:
- I've never seen anyone care about the identity of Integer.
- nor have I ever seen (nor do I want to) anyone lock on Integer.


[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.

These extra rules for "mutable objects being effectively encapsulated &
immutable" are quite complex;  almost certainly too complex for a compiler
or language spec, in determining fields to be used/ or which may be used
for equals()/ hashCode().

However, they might be quite good for an analyzer :)


Regards,
Thomas