> Safety-wise, taking transferring ownership is fraught True, or at the very least a true-ism we generally accept.
But that's still a deliberate choice to make that makes a performance tradeoff. The risk of misuse is proportional always to the exposure of and audience of the api. On Wed, Aug 24, 2022 at 10:28 AM Roger Riggs <roger.ri...@oracle.com> wrote: > Hi, > > Safety-wise, taking transferring ownership is fraught, the new owner can't > be certain that the original owner hasn't kept a reference to it or to its > implementation and might be mucking around with it behind the new owners > back. > > Its cleaner to design the APIs to be defensive, either the API should > handle the List creation itself (and only expose immutable Lists) or make > defensive copies before using or saving it. > > $0.02, Roger > > > On 8/24/22 9:38 AM, 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 > > 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. >>> > >>> > >>> >>> >
