Hmm… so you’re saying that the most natural interpretation of “[…] guaranteed to traverse elements as they existed upon construction exactly once” Is roughly “[…] guaranteed to traverse elements as they existed upon construction-or-later exactly once” Or not quite?
From: Viktor Klang <[email protected]> Sent: Friday, March 27, 2026 1:01 PM To: Yagnatinsky, Mark (Associated) <[email protected]>; [email protected] Subject: Re: [External] : weakly consistent iterators spec seems misleading? From CHM (https: //docs. oracle. com/en/java/javase/26/docs/api/java. base/java/util/concurrent/ConcurrentHashMap. html): «Similarly, Iterators, Spliterators and Enumerations return elements reflecting the state of the hash table at some point at From CHM (https://docs.oracle.com/en/java/javase/26/docs/api/java.base/java/util/concurrent/ConcurrentHashMap.html<https://urldefense.com/v3/__https:/docs.oracle.com/en/java/javase/26/docs/api/java.base/java/util/concurrent/ConcurrentHashMap.html__;!!DEyr4sPAfcQg!Xfa_xd_D81oslAwWbNgiyZL0p276SkFEZWyPPt2UD0WKs7JWRB0tHVbIZr8qZpr8ZALmvYSlSuaL4XB2gOPjT9XKBs4JXw$>): «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. » From Weakly consistent iterators (https://docs.oracle.com/en/java/javase/26/docs/api/java.base/java/util/concurrent/package-summary.html#Weakly<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!Xfa_xd_D81oslAwWbNgiyZL0p276SkFEZWyPPt2UD0WKs7JWRB0tHVbIZr8qZpr8ZALmvYSlSuaL4XB2gOPjT9XbvWj4ag$>): «they are guaranteed to traverse elements as they existed upon construction exactly once, and may (but are not guaranteed to) reflect any modifications subsequent to construction.» If CHM-derived iterators reflect the state of the hash table at-least-from-the-time-of-creation-of-the-iterator, it will traverse the elements as they existed at that time. I don't see that there's any contradiction there. On 2026-03-27 15:37, Yagnatinsky, Mark wrote: Okay, then can you explain how to reconcile this phrasing “[…] are guaranteed to traverse elements as they existed upon construction exactly once” (from the weakly consistent definition) With the fact that the iterator almost surely won’t show me elements removed before the traversal reaches them? Am I just failing at parsing the English here? From: Viktor Klang <[email protected]><mailto:[email protected]> Sent: Friday, March 27, 2026 10:29 AM To: Yagnatinsky, Mark (Associated) <[email protected]><mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: Re: [External] : weakly consistent iterators spec seems misleading? 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” 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]><mailto:[email protected]> Sent: Friday, March 27, 2026 9:55 AM To: [email protected]<mailto:[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 -- Cheers, √ Viktor Klang Software Architect, Java Platform Group Oracle
