The Stream API is definitely significantly different from the Function API. Maybe you mean that Stream is significantly different from Iterator (which is surely is)?
Everything you say about deprecation seems very fair to me, and that's what happened to a number of other types (e.g. in jena-core). I had a PR in to actually remove these guys under discussion. (Mentioned in the comments to this ticket.) I will rework that to only deprecate them and add advice on how to use the Java 8 idioms instead, and we can take that into your proposed other ticket. As far as Java 8 adoption, I appreciate the difficulties there. I will step out of the way and let others discuss that, because I am lucky to be in a position where the issue is not too urgent. --- A. Soroka The University of Virginia Library On Jun 22, 2015, at 4:23 PM, Claude Warren <cla...@xenei.com> wrote: > I must have misunderstood a post from Andy then. My error. I thought > there was a comment from Andy that indicated that Supplier was part of > Stream and that Stream was significantly different from Function. As I > said, my error and I am happy to drop that point. > > As for the code base, for any publicly accessible surfaces we have to > consider that they may be used outside of our base in products built upon > Jena. The the class was exposed then removing it should not be cut and > done. (I learned this lesson the hard way). Naturally this does not apply > to internal code where the interface remains the same and the > implementation changes. > > Thus my suggestion to fill out the class. > > I also proposed that we open an Epic to discuss how to move toward the > Function approach you propose. I think that we will need a two prong > approach. Retain the current interfaces that have been publicly available > while marking them as deprecated and pointing to the Function approach as > the replacement. > > I would think that we could mark as deprecated and indicate that they will > be removed in 3.1.0 (or some such). Perhaps we should discuss how long to > keep deprecated bits around before removing them. I think that 3.x.y > deprecates something then 3.x+1.0 should be the earliest it should be > removed. > > I also have concerns about the full on Java 8 adoption path we are on as > there are cases where Java 8 is not available. Working for IBM I can tell > you that we still support Java 6 and that the Java 6 IBM ships is patched > to resolve security issues. But the fact remains that there are > environment that are not at java 8 and won't be there any time soon. Our > customers are reticent to move java versions in their large environments. > I have a project where we are going to have to back port Jena 13.1 to Java > 6 (if possible). But that is neither here nor there with regards to the > topic at hand. > > Claude > > On Mon, Jun 22, 2015 at 9:03 PM, A. Soroka (JIRA) <j...@apache.org> wrote: > >> >> [ >> https://issues.apache.org/jira/browse/JENA-966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14596545#comment-14596545 >> ] >> >> A. Soroka edited comment on JENA-966 at 6/22/15 8:02 PM: >> --------------------------------------------------------- >> >> Just as a sidenote for anyone following this who is not familiar with the >> use of {{Supplier}}: {{Supplier}} is not part of the Java 8 Stream API, >> it's part of the Function API. It is a very simple SAM interface that is >> intended to hold a computation. So one might do: >> >> {code:language=java} >> # the only costs of the line below are an assignment and object creation >> Supplier<Foo> fooForLater = () -> expensiveCompution(); >> >> # do some other stuff >> >> # the line below is where we pay the cost of expensiveCompution() >> Foo myFoo = fooForLater.get(); >> {code} >> >> >> was (Author: ajs6f): >> Just as a sidenote for anyone following this who is not familiar with the >> use of {{Supplier}}: {{Supplier}} is not part of the Java 8 Stream API, >> it's part of the Function API. It is a very simple SAM interface that is >> intended to hold a computation. So one might do: >> >> {code:language=java} >> # the only cost of the line below is an assignment >> Supplier<Foo> fooForLater = () -> expensiveCompution(); >> >> # do some other stuff >> >> # the line below is where we pay the cost of expensiveCompution() >> Foo myFoo = fooForLater.get(); >> {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) >> > > > > -- > I like: Like Like - The likeliest place on the web > <http://like-like.xenei.com> > LinkedIn: http://www.linkedin.com/in/claudewarren
