On 26/08/2022 18:54, Ethan McCue wrote:
If the collections would decide whether or not to copy, I don't think
just requesting an immutable reference would be enough.
static List listCopy(Collection coll) {
if (coll instanceof List12 || (coll instanceof ListN && !
If the collections would decide whether or not to copy, I don't think just
requesting an immutable reference would be enough.
static List listCopy(Collection coll) {
if (coll instanceof List12 || (coll instanceof ListN && !
((ListN)coll).allowNulls)) {
return (List)coll;
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
ote:
>
>
> --
>
> *From: *"Ethan McCue"
> *To: *"Remi Forax"
> *Cc: *"John Hendrikx" , "core-libs-dev" <
> core-libs-dev@openjdk.org>
> *Sent: *Wednesday, August 24, 2022 4:27:01 PM
> *Subject: *Re: Proposal: C
> From: "Ethan McCue"
> To: "Remi Forax"
> Cc: "John Hendrikx" , "core-libs-dev"
>
> Sent: Wednesday, August 24, 2022 4:27:01 PM
> Subject: Re: Proposal: Collection mutability marker interfaces
>> so it's perhaps better to ca
> 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
On Wed, Aug 24, 2022 at 10:03 AM Remi Forax wrote:
>
>
> --
>
> *From: *"Ethan McCue"
> *To: *"John Hendrikx"
> *Cc: *"core-libs-dev"
> *Sent: *Wednesday, August 24, 2022 3:38:26 PM
> *Subject: *Re: Propo
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
> From: "Ethan McCue"
> To: "John Hendrikx"
> Cc: "core-libs-dev"
> Sent: Wednesday, August 24, 2022 3:38:26 PM
> Subject: Re: Proposal: Collection mutability marker interfaces
> A use case that doesn't cover is adding to a collection.
> Sa
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
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 immutableCopy(); // returns a (shallow) immutable copy if
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 wrote:
> List.copyOf already does what you want.
>
>
>
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
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
14 matches
Mail list logo
