[
https://issues.apache.org/jira/browse/CASSANDRA-9985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14658264#comment-14658264
]
Jason Brown edited comment on CASSANDRA-9985 at 8/5/15 2:15 PM:
----------------------------------------------------------------
Rereading through the guava AbstractIterator code, I didn't feel it to be too
overbearing (there's the state machine and a Precondition call). TBH, I'm kinda
mixed on this - I appreciate one less external dependency, and the patch is
simple enough. If others are fine with the change, I will be, as well.
Nit:
- in your AbstractIterator.remove(), it's a no-op. In the guava version, it
throws an UnsupportedOperationException as it derives from UnmodifiableIterator
was (Author: jasobrown):
Rereading through the guava AbstractIterator code, I didn't feel it to be too
overbearing (there's the state machine and a Precondition call). TBH, I'm kinda
mixed on this - I appreciate one less external dependency, and the patch is
simple enough. If others are fine with the change, I will be, as well.
Nit:
- in your AbstractIterator.remove(), it's a no-op. In the guava version, it
throws a UnsupportedOperationException as it derives from UnmodifiableIterator
> Introduce our own AbstractIterator
> ----------------------------------
>
> Key: CASSANDRA-9985
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9985
> Project: Cassandra
> Issue Type: Sub-task
> Components: Core
> Reporter: Benedict
> Assignee: Benedict
> Priority: Trivial
> Fix For: 3.0.0 rc1
>
>
> The Guava AbstractIterator not only has unnecessary method call depth, it is
> difficult to debug without attaching source. Since it's absolutely trivial to
> write our own, and it's used widely within the codebase, I think we should do
> so.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
