[
https://issues.apache.org/jira/browse/JCR-3555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13619723#comment-13619723
]
Lukas Eder commented on JCR-3555:
---------------------------------
I agree that using the term "iterable" can be misleading. On the other hand,
this would also apply to a couple of types in the same package, which wrap an
Iterator and call themselves "Iterable".
About JcrUtils: Many methods in there suffer from the same problem! Take
JcrUtils.getProperties(Node) as an example:
public static Iterable<Property> getProperties(Node node)
throws RepositoryException {
return new PropertyIterable(node.getProperties());
}
It pretends to return a true "Iterable", when in fact it just adapts to the
"Iterable" interface, wrapping a one-shot Iterator. A possible solution to this
issue could be to add a marker interface and return that from the utility
methods:
/** Javadoc to explain semantics */
public interface OneShotIterable<E> extends Iterable<E> {}
Note, the advantage of using the same term for all Iterator types (whether it
be "iterable" or something else) is the fact that API users may find this more
natural than having to look up the most appropriate method name in a large list
of utility methods...
> Add a static utility to transform JCR Iterators into Iterables
> --------------------------------------------------------------
>
> Key: JCR-3555
> URL: https://issues.apache.org/jira/browse/JCR-3555
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
> Components: jackrabbit-jcr-commons
> Affects Versions: 2.6
> Reporter: Lukas Eder
> Priority: Minor
> Attachments: Iterators.java.patch
>
>
> I have stumbled upon the utility classes in the
> org.apache.jackrabbit.commons.iterator package. They're quite useful in
> principle, but not applied thoroughly. E.g. there are missing wrapper types
> for at least these JCR Iterators:
> - AccessControlPolicyIterator
> - EventIterator
> - EventListenerIterator
> - NodeTypeIterator
> - VersionIterator
> Instead of adding more classes, it might be useful to create static methods
> for the job. Using static methods from a single class (with static imports)
> is a bit more convenient than looking up and creating the wrapper types using
> "new WrapperType(...)"
> An example:
> org.apache.jackrabbit.commons.iterator.Iterators.iterable
> // And then:
> for (Node n : iterable(parent.getNodes())) {
> // Do stuff with n
> }
> Please find attached a .patch file containing an implementation suggestion.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
