[10?] RFR: 8193128: Reduce number of implementation classes returned by List/Set/Map.of()
john.r.rose at oracle.com
Fri Dec 22 19:57:26 UTC 2017
On Dec 21, 2017, at 5:31 PM, Stuart Marks <stuart.marks at oracle.com> wrote:
> I'd like a blanket assertion that view collections are not serializable.
> Now this should be considered distinct from whether view collections are value-based; I'm fine with considering view collections to be value-based. It's just that some value-based collections are serializable and others aren't. In particular, given a serializable, value-based list, a sublist should not be serializable but it can be value-based. A sublist of a sublist should also not be serializable and can be value-based, and in this case we can do short-circuiting such as 'return this' if we like.
The two concerns can be separated, but they necessarily
have a priority, and I think you have got the priority backward.
Here's the way I see it:
1. Value-based aggregates are inherently lossless when
serialized, and so should (in general) be made serializable.
2. Views are generally lossy when serialized, *if the backing
store has a significant identity*, and should (in general) not
be made serializable.
If we are going to make blanket statements, I claim the first
is more fundamental than the second. The second has
priority only in history, since serialization was invented before
the value-based distinction.
I think we should apply the rules in logical order 1, then 2,
not historical order 2, then 1.
More information about the core-libs-dev