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, patr...@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.
--
