> I think the original idea was that the "general contract" was that
> collections contained elements whose membership was defined by equals().
> However, for a very long time now there have been collections in the JDK such
> as SortedSet and IdentityHashMap (more precisely, IdentityHashMap's
On 2/15/19 11:30 AM, Alan Snyder wrote:
I think this situation is a mess.
The “general contract” of a Collection, I believe, is that it contains zero
or more identified member objects, as defined by appropriate equals() method.
I know this is hard to specify precisely, but I presume we all
I think this situation is a mess.
The “general contract” of a Collection, I believe, is that it contains zero or
more identified member objects, as defined by appropriate equals() method. I
know this is hard to specify precisely, but I presume we all “know it when we
see it”.
There is value
On 2/14/19 9:30 AM, Alan Snyder wrote:
Care must be exercised if this method is used on collections that
do not comply with the general contract for {@code Collection}.
So, what does this mean? Are we catering to incorrect implementations?
I think this is a quote from the specification of
On Wed, Feb 13, 2019 at 6:45 PM Stuart Marks
wrote:
>
> If we all agree on this, I'll proceed with working up a changeset for
> JDK-6394757.[3] It's time to fix this one.
>
Thanks for taking on the fixing of this unfixable problem.
It's important to do lots of documentation/guidance work, esp.
Right, I see that now.
Care must be exercised if this method is used on collections that
do not comply with the general contract for {@code Collection}.
So, what does this mean? Are we catering to incorrect implementations?
> On Feb 13, 2019, at 9:07 PM, Stuart Marks wrote:
>
> On 2/13/19
On 2/13/19 7:22 PM, Alan Snyder wrote:
If we take this route, how about changing the parameter type to Iterable?
Won't work. Where I've ended up is that we need to iterate over "this"
collection and, for each element, call contains() on the parameter. The
AbstractCollection.removeAll()
()).add(s);
>> }
>> Set toRemove = lengthMap.keySet();
>> System.out.println("List before: " + strings);
>> System.out.println("Set to remove: " + toRemove);
>> strings.removeAll(toRemove);
>> System.out.println(
System.out.println("List after:" + strings);
}
}
/* --- snip --- */
List before: [The, quick, brown, fox, jumps, over, the, lazy, dog]
Set to remove: [The, over, quick]
List after:[]
/Michael
From: core-libs-dev on behalf of Tagir
Valeev
Sent: 08 February 201
On 2/8/19 5:13 AM, Tagir Valeev wrote:
I would argue that iterating the argument and calling remove() on "this" are the
right semantics, because you want set membership to be determined by this set,
not by whatever collection you pass as an argument. However, I note that
t Marks
Cc: core-libs-dev; Jan Peter Stotz
Subject: Re: JDK-6982173: Small problem causing thousands of wasted CPU hours
Hello!
> I would argue that iterating the argument and calling remove() on "this" are
> the
> right semantics, because you want set membership to be
Hello!
> I would argue that iterating the argument and calling remove() on "this" are
> the
> right semantics, because you want set membership to be determined by this set,
> not by whatever collection you pass as an argument. However, I note that
> AbstractCollection.removeAll and other
Hi Stuart.
It looks like the web sites and services I use when developing and those
you use are fundamentally different or may be we use just different
search engines, because when I have programming problems I usually not
end up on Twitter or Reddit or DZone. And the existence of this
On 1/23/19 12:05 PM, Jan Peter Stotz wrote:
like many other I ran into bug JDK-698217 which is about AbstractSet.removeAll()
and it's "aptitude" in wasting CPU time if you accidentally hit this bug. And
there are hundred of developers hitting this bug every year.
I simply don't understand why
Hi.
Unfortunately in my last message I made mistake and mixed up the two
sections. The main reasons for were first too many coding hours
yesterday and second I had investigated this issue not yesterday but
some weeks ago. During the last weeks I searched a way to participate in
OpenJDK
Hi Jan,
I'm amazed to see this performance problem has persisted for so long. As a
Java developer, I wasn't even aware of it, so thanks for the information.
>
> The relevant part of the current implementation is as follows:
>
> if (size() > c.size()) {
> for (Object e : c)
16 matches
Mail list logo
