If the collections would decide whether or not to copy, I don't think just
requesting an immutable reference would be enough.
static <E> List<E> listCopy(Collection<? extends E> coll) {
if (coll instanceof List12 || (coll instanceof ListN && !
((ListN<?>)coll).allowNulls)) {
return (List<E>)coll;
} else {
return (List<E>)List.of(coll.toArray()); // implicit nullcheck
of coll
}
}
The two things that List.copyOf needs to know are that the list is
immutable, but also that it isn't a variant that might contain a null.
So maybe instead of
List<T> y = x.immutableCopy();
It could be appropriate to use the spliterator approach and request a copy
which has certain characteristics.
static <E> List<E> listCopy(Collection<? extends E> coll) {
if (coll instanceof List<?> list) {
return list.copyWhere(EnumSet.of(IMMUTABLE, DISALLOW_NULLS));
} else {
return (List<E>)List.of(coll.toArray()); // implicit nullcheck
of coll
}
}
but that leaves open whether you would want to request the *presence* of
capabilities or the *absence* of them.
Maybe
List.of().copyWhere();
Could be defined to give a list where it is immutable and nulls aren't
allowed. And then
List.of(1, 2, 3).copyWhere(EnumSet.of(ADDABLE, NULLS_ALLOWED));
gives you a mutable copy where nulls are allowed.
This still does presume that making a copy if a capability isn't present is
the only use of knowing the capabilities - which from the conversation so
far isn't that unrealistic
On Fri, Aug 26, 2022 at 11:20 AM John Hendrikx <john.hendr...@gmail.com>
wrote:
>
> On 24/08/2022 15:38, Ethan McCue wrote:
>
> A use case that doesn't cover is adding to a collection.
>
> Say as part of a method's contract you state that you take ownership of a
> List. You aren't going to copy even if the list is mutable.
>
> Later on, you may want to add to the list. Add is supported on ArrayList
> so you don't need to copy and replace your reference, but you would if the
> list you were given was made with List.of or Arrays.asList
>
> I don't think this is a common enough use case that should be catered
> for. It might be better handled with concurrent lists instead.
>
> The most common use case by far is wanting to make sure a collection
> you've received is not going to be modified while you are working with it.
> I don't think another proposal which does cover the most common cases
> should be dismissed out of hand because it doesn't support a rather rare
> use case.
> --John
>
>
>
> On Wed, Aug 24, 2022, 8:13 AM John Hendrikx <john.hendr...@gmail.com>
> wrote:
>
>> Would it be an option to not make the receiver responsible for the
>> decision whether to make a copy or not? Instead put this burden (using
>> default methods) on the various collections?
>>
>> If List/Set/Map had a method like this:
>>
>> List<T> immutableCopy(); // returns a (shallow) immutable copy if
>> list is mutable (basically always copies, unless proven otherwise)
>>
>> Paired with methods on Collections to prevent collections from being
>> modified:
>>
>> Collections.immutableList(List<T>)
>>
>> This wrapper is similar to `unmodifiableList` except it implements
>> `immutableCopy` as `return this`.
>>
>> Then for the various scenario's, where `x` is an untrusted source of List
>> with unknown status:
>>
>> // Create a defensive copy; result is a private list that cannot be
>> modified:
>>
>> List<T> y = x.immutableCopy();
>>
>> // Create a defensive copy for sharing, promising it won't ever
>> change:
>>
>> List<T> y = Collections.immutableList(x.immutableCopy());
>>
>> // Create a defensive copy for mutating:
>>
>> List<T> y = new ArrayList<>(x); // same as always
>>
>> // Create a mutable copy, modify it, then expose as immutable:
>>
>> List<T> y = new ArrayList<>(x); // same as always
>>
>> y.add( <some element> );
>>
>> List<T> z = Collections.immutableList(y);
>>
>> y = null; // we promise `z` won't change again by clearing the only
>> path to mutating it!
>>
>> The advantage would be that this information isn't part of the type
>> system where it can easily get lost. The actual implementation knows best
>> whether a copy must be made or not.
>>
>> Of course, the immutableList wrapper can be used incorrectly and the
>> promise here can be broken by keeping a reference to the original (mutable)
>> list, but I think that's an acceptable trade-off.
>>
>> --John
>>
>> PS. Chosen names are just for illustration; there is some discussion as
>> what "unmodifiable" vs "immutable" means in the context of collections that
>> may contain elements that are mutable. In this post, immutable refers to
>> shallow immutability .
>> On 24/08/2022 03:24, Ethan McCue wrote:
>>
>> Ah, I'm an idiot.
>>
>> There is still a proposal here somewhere...maybe. right now non jdk lists
>> can't participate in the special casing?
>>
>> On Tue, Aug 23, 2022, 9:00 PM Paul Sandoz <paul.san...@oracle.com> wrote:
>>
>>> List.copyOf already does what you want.
>>>
>>>
>>> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/List.java#L1068
>>>
>>> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/ImmutableCollections.java#L168
>>>
>>> Paul.
>>>
>>> > On Aug 23, 2022, at 4:49 PM, Ethan McCue <et...@mccue.dev> wrote:
>>> >
>>> > Hi all,
>>> >
>>> > I am running into an issue with the collections framework where I have
>>> to choose between good semantics for users and performance.
>>> >
>>> > Specifically I am taking a java.util.List from my users and I need to
>>> choose to either
>>> > * Not defensively copy and expose a potential footgun when I pass that
>>> List to another thread
>>> > * Defensively copy and make my users pay an unnecessary runtime cost.
>>> >
>>> > What I would really want, in a nutshell, is for List.copyOf to be a
>>> no-op when used on lists made with List.of().
>>> >
>>> > Below the line is a pitch I wrote up on reddit 7 months ago for a
>>> mechanism I think could accomplish that. My goal is to share the idea a bit
>>> more widely and to this specific audience to get feedback.
>>> >
>>> >
>>> https://www.reddit.com/r/java/comments/sf8qrv/comment/hv8or92/?utm_source=share&utm_medium=web2x&context=3
>>> >
>>> > Important also for context is Ron Pressler's comment above.
>>> > --------------
>>> >
>>> > What if the collections api added more marker interfaces like
>>> RandomAccess?
>>> >
>>> > It's already a common thing for codebases to make explicit null checks
>>> at error boundaries because the type system can't encode null |
>>> List<String>.
>>> >
>>> > This feels like a similar problem.
>>> > If you have a List<T> in the type system then you don't know for sure
>>> you can call any methods on it until you check that its not null. In the
>>> same way, there is a set of methods that you don't know at the
>>> type/interface level if you are allowed to call.
>>> >
>>> > If the List is actually a __
>>> > Then you can definitely call
>>> > And you know other reference holders might call
>>> > And you can confirm its this case by
>>> > null
>>> > no methods
>>> > no methods
>>> > list == null
>>> > List.of(...)
>>> > get, size
>>> > get, size
>>> > ???
>>> > Collections.unmodifiableList(...)
>>> > get, size
>>> > get, size, add, set
>>> > ???
>>> > Arrays.asList(...)
>>> > get, size, set
>>> > get, size, set
>>> > ???
>>> > new ArrayList<>()
>>> > get, size, add, set
>>> > get, size, add, set
>>> > ???
>>> > While yes, there is no feasible way to encode these things in the type
>>> system. Its not impossible to encode it at runtime though.
>>> > interface FullyImmutable {
>>> > // So you know the existence of this implies the absence
>>> > // of the others
>>> > default Void cantIntersect() { return null; }
>>> > }
>>> >
>>> > interace MutationCapability {
>>> > default String cantIntersect() { return ""; }
>>> > }
>>> >
>>> > interface Addable extends MutationCapability {}
>>> > interface Settable extends MutationCapability {}
>>> >
>>> > If the List is actually a __
>>> > Then you can definitely call
>>> > And you know other reference holders might call
>>> > And you can confirm its this case by
>>> > null
>>> > no methods
>>> > no methods
>>> > list == null
>>> > List.of(...)
>>> > get, size
>>> > get, size
>>> > instanceof FullyImmutable
>>> > Collections.unmodifiableList(...)
>>> > get, size
>>> > get, size, add, set
>>> > !(instanceof Addable) && !(instanceof Settable)
>>> > Arrays.asList(...)
>>> > get, size, set
>>> > get, size, set
>>> > instanceof Settable
>>> > new ArrayList<>()
>>> > get, size, add, set
>>> > get, size, add, set
>>> > instanceof Settable && instanceof Addable
>>> > In the same way a RandomAccess check let's implementations decide
>>> whether they want to try an alternative algorithm or crash, some marker
>>> "capability" interfaces would let users of a collection decide if they want
>>> to clone what they are given before working on it.
>>> >
>>> >
>>> > --------------
>>> >
>>> > So the applicability of this would be that the list returned by
>>> List.of could implement FullyImmutable, signifying that there is no caller
>>> which might have a mutable handle on the collection. Then List.of could
>>> check for this interface and skip a copy.
>>> >
>>> >
>>>
>>>
