[
https://issues.apache.org/jira/browse/JENA-966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14596530#comment-14596530
]
A. Soroka edited comment on JENA-966 at 6/22/15 7:44 PM:
---------------------------------------------------------
There's a few points here:
- I have _not_ suggested anything about {{Stream}}. They just don't have
anything to do with this. As [~andy.seaborne] pointed out, {{Stream}}s are not
{{Iterator}}s, period. They just have no relevance here, so I'm not sure what
your objection is, in that regard.
- "Are you proposing we leave the entire installed base and extended code base
behind at the 3.0 juncture?" I think that's a bit disingenuous. I'm suggesting,
as I said above, getting rid of three or four types that are either not used
anywhere in the code base or used only once. That's hardly leaving "the entire
installed base" behind, is it? And if a major version change _isn't_ the time
to make this kind of clean-up, when is? Are all unused but released classes in
Jena eternal and indestructible?
- Getting an {{Iterator}} out of a {{Supplier<Iterator>}} is as hard as calling
{{Supplier::get}}. One method. It is exactly the timing of that method call
that introduces the laziness.
I'm happy to let this be. I just don't see as much value in the effort spent
filling out a class that has never been used as I do in taking advantage of the
much more idiomatic approach now available in Java 8, as well as removing some
unused code.
was (Author: ajs6f):
There's a few points here:
- I have _not_ suggested anything about {{Stream}}s. They just don't have
anything to do with this. As [~afs] pointed out, {{Stream}}s are not
{{Iterator}}s, period. They just have no relevance here, so I'm not sure what
your objection is, in that regard.
- "Are you proposing we leave the entire installed base and extended code base
behind at the 3.0 juncture?" I think that's a bit disingenuous. I'm suggesting,
as I said above, getting rid of three or four types that are either not used
anywhere in the code base or used only once. That's hardly leaving "the entire
installed base" behind, is it? And if a major version change _isn't_ the time
to make this kind of clean-up, when is? Are all unused but released classes in
Jena eternal and indestructible?
- Getting an {{Iterator}} out of a {{Supplier<Iterator>}} is as hard as calling
{{Supplier::get}}. One method. It is exactly the timing of that method call
that introduces the laziness.
I'm happy to let this be. I just don't see as much value in the effort spent
filling out a class that has never been used as I do in taking advantage of the
much more idiomatic approach now available in Java 8, as well as removing some
unused code.
> LazyIterator
> ------------
>
> Key: JENA-966
> URL: https://issues.apache.org/jira/browse/JENA-966
> Project: Apache Jena
> Issue Type: Bug
> Components: Core
> Affects Versions: Jena 3.0.0
> Reporter: Claude Warren
> Assignee: Claude Warren
>
> LazyIterator is an abstract class. The documentation indicates that the
> create() method needs to be overridden to create an instance. From this I
> would expect that
> now LazyIterator(){
> @Override
> public ExtendedIterator<Model> create() {
> ...
> }};
> Would work however LazyIterator does not override:
> remoteNext(), andThen(), toList(), and toSet().
> I believe these should be implemented in the class.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
