You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Gary D. Gregory (Jira)" <ji...@apache.org> on 2024/10/20 12:11:00 UTC
[jira] [Resolved] (COLLECTIONS-856) Document the interaction between PeekingIterator and FilteredIterator
[ https://issues.apache.org/jira/browse/COLLECTIONS-856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Gary D. Gregory resolved COLLECTIONS-856.
-----------------------------------------
Fix Version/s: 4.5.0-M3
Assignee: Gary D. Gregory
Resolution: Fixed
[~benjaminconfino]
In git master and snapshot builds.
TY!
> Document the interaction between PeekingIterator and FilteredIterator
> ---------------------------------------------------------------------
>
> Key: COLLECTIONS-856
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-856
> Project: Commons Collections
> Issue Type: Improvement
> Components: Iterator
> Affects Versions: 4.5.0-M1
> Reporter: Benjamin Confino
> Assignee: Gary D. Gregory
> Priority: Minor
> Fix For: 4.5.0-M3
>
>
> If you have a FilteredIterator, call peek and get an element x. Then something modifies the state of that x. Then you call peek again FilteredIterator will return x even if x no longer passes the predicate.
> I think this behaviour is correct. I would not expect the the state of an iterator to change unless I called a method like next(), and I would not expect an exception like ConcurrentModificationException when the collection has not changed.
> However its an obscure edge case so it might be worth documenting it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)