[
https://issues.apache.org/jira/browse/JENA-1427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16257380#comment-16257380
]
A. Soroka edited comment on JENA-1427 at 11/17/17 6:42 PM:
-----------------------------------------------------------
You can definitely convert any {{Iterator}} into a {{Stream}} client-side, and
Jena even has convenience methods therefor:
{{org.apache.jena.atlas.iterator.Iter.asStream(Iterator<T>)}}.
But an {{Iterator}} isn't a {{Stream}} and they should be distinguished pretty
clearly.
(This took me a long time to understand, and really I had to read what Brian
Goetz wrote
[here|https://www.ibm.com/developerworks/library/j-java-streams-3-brian-goetz/index.html]
and then [~andy.seaborne] had to beat it into my head. The sentence (from that
article) "When the terminal operation is initiated, the stream implementation
picks an execution plan." speaks volumes about the difference in these
abstractions. An {{Iterator}} generally doesn't "pick an execution plan".)
An {{Iterator}} is a source of inputs, a {{Stream}} is a _composition of
functions_ attached to a source of inputs. If you don't believe me, take a look
at the difference between something {{java.util.AbstractList.Itr<E>}} and
something like {{java.util.stream.ReferencePipeline<P_IN, P_OUT>}}.
I really think this kind of functionality might best be left client-side but
maybe you can send a PR with what you'd like and we can get more eyes on it?
was (Author: ajs6f):
You can definitely convert any {{Iterator}} into a {{Stream}} client-side, and
Jena even has convenience methods therefor:
{{org.apache.jena.atlas.iterator.Iter.asStream(Iterator<T>)}}.
But an {{Iterator}} isn't a {{Stream}} and they should be distinguished pretty
clearly.
(This took me a long time to understand, and really I had to read what Brian
Goetz wrote
[here|https://www.ibm.com/developerworks/library/j-java-streams-3-brian-goetz/index.html]
and then [~andy.seaborne] had to beat it into my head. The sentence (from that
article) "When the terminal operation is initiated, the stream implementation
picks an execution plan." speaks volumes about the difference in these
abstractions. An {{Iterator}} generally doesn't "pick an execution plan".)
An {{Iterator}} is a source of inputs, a {{Stream}} is a _composition of
functions_ attached to a source of inputs. If you don't believe me, take a look
at the difference between something {{java.util.AbstractList.Itr<E>}} and
something like {{java.util.stream.ReferencePipeline<P_IN, P_OUT>}}.
I really think this kind of functionality might best be left client-sidel but
maybe you can send a PR with what you'd like and we can get more eyes on it?
> Add nextOrElse() method in ExtendedIterator
> -------------------------------------------
>
> Key: JENA-1427
> URL: https://issues.apache.org/jira/browse/JENA-1427
> Project: Apache Jena
> Issue Type: Improvement
> Components: Core
> Affects Versions: Jena 3.5.0
> Reporter: Adam Jacobs
> Priority: Trivial
> Labels: easytask
>
> Allow a functional approach for returning a default value or throwing a
> custom exception from a Jena iterator.
> The following method may be added to the ExtendedIterator interface.
> {noformat}
> /**
> Answer the next object, if it exists, otherwise invoke the
> _supplier_.
> */
> public default T nextOrElse( Supplier<T> supplier ) {
> return hasNext() ? next() : supplier.get();
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
