It may be discussed already but based on the definition as you just
changed,
would it make sense to have a way to create such a Set/List/Map based
on a
existing mutable implementation? We use a the builder pattern a lot to
create
immutable objects that get serialized later.
At the moment we have to do the following in order to decouple the
builders actual
set content in case the builder is re-used:
Set<?> immutable = Collections.unmodifiableSet(new
HashSet<>(builderSet)));
Instead of may be using:
Set<?> immutable = Set.of(builderSet);
The same pattern would also apply to List/Map
- Patrick
On 2015-12-04 01:58, Stuart Marks wrote:
Small refresh here: after some consultation with Brian Goetz and John
Rose, I've updated the class doc text covers immutability and
value-based. They now say,
* They are structurally immutable. Elements cannot be added,
removed, or replaced. Attempts to do so result in
UnsupportedOperationException. However, if the contained elements are
themselves mutable, this may cause the List's contents to appear to
change.
[and similar for Set and Map]
* They are value-based. Callers should make no assumptions about the
identity of the returned instances. Factories are free to create new
instances or reuse existing ones. Therefore, identity-sensitive
operations on these instances (reference equality (==), identity hash
code, and synchronization) are unreliable and should be avoided.
--
