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

[Stuart Marks]

Hi Patrick,

Please see my response to a similar query from Peter Levart:

http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-November/036909.html

Briefly, this is something we should consider as a future extension. The current 
workaround is to load values into an array and then call the appropriate varargs 
factory method.

s'marks

On 12/3/15 11:40 PM, patrick at reini.net wrote:
> 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.
>>
>> --
>>