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)