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
