No, looking at the CHM javadoc it specifies that iterators are weakly
consistent.
On 2026-03-27 15:09, Yagnatinsky, Mark wrote:
Ah, I see. So does this mean that CHM does not promise that it’s
iterators uphold the full-fledged “weakly consistent” guarantee
described in the package overview?
*From:*Viktor Klang <[email protected]>
*Sent:* Friday, March 27, 2026 9:55 AM
*To:* [email protected]
*Subject:* Re: [External] : weakly consistent iterators spec seems
misleading?
This is the most recent documentation for this (for
ConcurrentHashMap): /«Similarly, Iterators, Spliterators and
Enumerations return elements reflecting the state of the hash table at
some point at or since the creation of the iterator/enumeration.
This is the most recent documentation for this (for ConcurrentHashMap):
/«Similarly, Iterators, Spliterators and Enumerations return elements
reflecting the state of the hash table at some point at or since the
creation of the iterator/enumeration. They do not throw
ConcurrentModificationException.» -
/https://urldefense.com/v3/__https://docs.oracle.com/en/java/javase/26/docs/api/java.base/java/util/concurrent/ConcurrentHashMap.html__;!!DEyr4sPAfcQg!SWSHJo8BpImmgi5iEAIgHXmaZfMLzhX-gI-m7m7XbgaqdZ9aOAEupLGTHGx-UNB6d6P2VxS8YP_cNzrLKxJp_H6WP7gjGQ$
<https://urldefense.com/v3/__https:/docs.oracle.com/en/java/javase/26/docs/api/java.base/java/util/concurrent/ConcurrentHashMap.html__;!!DEyr4sPAfcQg!SWSHJo8BpImmgi5iEAIgHXmaZfMLzhX-gI-m7m7XbgaqdZ9aOAEupLGTHGx-UNB6d6P2VxS8YP_cNzrLKxJp_H6WP7gjGQ$>
Also, here's the latest documentation on weakly consistent iterators:
https://urldefense.com/v3/__https://docs.oracle.com/en/java/javase/26/docs/api/java.base/java/util/concurrent/package-summary.html*Weakly__;Iw!!DEyr4sPAfcQg!SWSHJo8BpImmgi5iEAIgHXmaZfMLzhX-gI-m7m7XbgaqdZ9aOAEupLGTHGx-UNB6d6P2VxS8YP_cNzrLKxJp_H4FLzSVzg$
<https://urldefense.com/v3/__https:/docs.oracle.com/en/java/javase/26/docs/api/java.base/java/util/concurrent/package-summary.html*Weakly__;Iw!!DEyr4sPAfcQg!SWSHJo8BpImmgi5iEAIgHXmaZfMLzhX-gI-m7m7XbgaqdZ9aOAEupLGTHGx-UNB6d6P2VxS8YP_cNzrLKxJp_H4FLzSVzg$>
On 2026-03-27 07:07, Yagnatinsky, Mark wrote:
> Resending because I was not a list member the first time.
>
> I'm not sure if this is the right list. Please redirect me if not.
>
> The docs for java.util.concurrent (Java Platform SE 8 )<https://urldefense.com/v3/__https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/package-summary.html__;!!DEyr4sPAfcQg!SWSHJo8BpImmgi5iEAIgHXmaZfMLzhX-gI-m7m7XbgaqdZ9aOAEupLGTHGx-UNB6d6P2VxS8YP_cNzrLKxJp_H4gOw4Xww$
<https://urldefense.com/v3/__https:/docs.oracle.com/javase/8/docs/api/java/util/concurrent/package-summary.html__;!!DEyr4sPAfcQg!SWSHJo8BpImmgi5iEAIgHXmaZfMLzhX-gI-m7m7XbgaqdZ9aOAEupLGTHGx-UNB6d6P2VxS8YP_cNzrLKxJp_H4gOw4Xww$>>
say that weakly consistent iterators:
> "[...] are guaranteed to traverse elements as they existed upon construction
exactly once"
> Does this mean that if an element is removed after traversal begins, they
will still see it?
> That would seem to mandate that everything works like CopyOnWriteArrayList.
> One could argue that the next part of the sentence overrides this:
> "[...] and may (but are not guaranteed to) reflect any modifications subsequent to
construction"
> But this does not strike me as the most natural reading.
> The more natural one is that:
>
> 1. The traversal sees everything that was already there
> 2. If you add new stuff, you might see some of it, or all of it, or none
of it.
> There's also an even worse case that I wish the docs were clearer about.
> Suppose I'm iterating through a ConcurrentHashMap, and during the iteration
add an element.
> This could of course cause a resize, and nodes could move all over the place.
> Does this mean that an iteration could miss a pre-existing element, even
though it was NEVER deleted?
> Even the second clause doesn't legitimize this, I think.
> I'm pretty sure that this doesn't happen with the current implementation,
since the nodes will either stay at the same index in the new array, or move to a
later index.
> But it's a complicated class and I've never tried to read it. And it could
change tomorrow.
> Does the spec on the interface forbid such things? I was sure it did, but an
LLM told me that such horrors are allowed.
> Admittedly, LLMs can often get things wrong, sometimes blatantly so, but it
would be nice to have something so explicit that getting things wrong is harder
than this.
>
> This is late for me so hopefully the above is semi-coherent
>
> ________________________________
>
> The information contained in this message is intended only for the recipient, and may be a
confidential attorney-client communication or may otherwise be privileged and confidential and
protected from disclosure. If the reader of this message is not the intended recipient, or an
employee or agent responsible for delivering this message to the intended recipient, please be
aware that any dissemination or copying of this communication is strictly prohibited. If you have
received this communication in error, please immediately notify us by replying to the message and
deleting it from your computer. S&P Global Inc. reserves the right, subject to applicable
local law, to monitor, review and process the content of any electronic message or information
sent to or from S&P Global Inc. e-mail addresses without informing the sender or recipient of
the message. By sending electronic message or information to S&P Global Inc. e-mail addresses
you, as the sender, are consenting to S&P Global Inc.
> processing any of your personal data therein.
--
Cheers,
√
Viktor Klang
Software Architect, Java Platform Group
Oracle
--
Cheers,
√
Viktor Klang
Software Architect, Java Platform Group
Oracle
