RFR(m): update 2: JEP 269 initial API and skeleton implementation (JDK-8139232)

[patrick at reini.net]

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