I think StreamXXX is the future but there is so much goodness in the functional approach that a fluent API build to work well with that paradigm ought to work well out of other paradigms.
The other day I was coding up something that parses record-organized .txt files and make triples and I'd chosen to make a model, stuff it with facts, write it out as TTL, clear the model and do it again for the next record because (i) I am trying to work the memory management system as little as possible, and (ii) I am not doing pure streaming because I like the way TTL handles blank nodes, collections, containers and such. The relationship between the Graph stuff and the Model stuff is complicated enough that I worry a lot about "if I do it this way will it make more WrapperWrapperWrapper objects" and I like the interface that Model provides for putting in the facts, except for that funny little thing that you can reuse the same property object over and over again even though the interface makes you feel dirty for doing so. I'd really like something that rolls off the fingers and can go from streaming to "model" mode without a lot of guff. On Tue, May 5, 2015 at 6:55 AM, Andy Seaborne <[email protected]> wrote: > Hi there, > > I've noticed a few more places where some Java 8 changes could be >> brought into play in the interest of simplification, and in >> particular, the use of Java 8 Streams seems like a nice way to go. It >> would let Jena cut out a fair bit of API and implementation code in >> favor of letting Java itself do the work. >> > > If API includes the directly public APIs, I think there is a bigger > discussion there. There is a balance to be struck between change for the > good and not creating too much of a gap between Jena2 and Jena3 making > migration more of an effort. > > At the moment, the migration is pretty simple (JENA-926 being the first > major API change proposed). > > Actually, there is a good case for working on an new API - Jena can > support multiple APIs over the Graph/Node core - and leaving the current > ones to minimise migration effort needed. > > (see also http://commonsrdf.incubator.apache.org/ which is at a very low > level, but above the level of Jena Node). > > Here is a small program of >> incremental changes that I'd like to propose: >> >> - We could move NiceIterator's methods up into ExtendedIterator as >> default implementations and factor NiceIterator out of existence. >> > > - Then, we could migrate the API of ExtendedIterator to be a close >> analog to a subset of the API of Java 8's Stream. (It's not too far >> away right now.) >> >> - Then, we could begin replacing the use of ExtendedIterator, its >> subtypes (e.g. StmtIterator), and their implementations with Java 8 >> Streams. That will certainly take a few steps in itself, since >> ExtendedIterator is in use all over, but I'm confident (perhaps >> arrogantly so {grin}) that replacing its use at some fairly low-lying >> levels (I think around and just below TripleStore.find(Triple)) will >> allow some quick replacement moves at the levels above. >> > > It's at this point where I want to understand the impact on the code that > is "out there". > > - Then, we could begin exposing Stream<T>s in the signatures of new >> methods on very public-facing types like Model. For example, by >> analogy to Model.listSubjects() returning ResIterator, there could >> also be Model.streamSubjects() returning Stream<Resource>. >> > > That's an interesting idea for an incremental move to streams. > > Paul - what are your thoughts on streamXXX vs new API approaches? > > If it is the way to go, listXXX can be left alone more. > > And then, I hope, the community would begin migrating away from the >> ExtendedIterator methods and to the Java 8 Stream<T> methods, because >> Stream has so much attractive functionality available. >> > > Yes, except a stream is not quite an iterator. (No remove, not sequential > by default). When thinking about a lot of application code already > written, these can make a difference. > > Does this seem like a useful direction of work? I believe it could be >> undertaken without being disruptive, and even without too much code >> churn except when introducing Stream into the core. If it sounds like >> a good idea, I would be happy to begin it. >> > > Straight to pull request is probably not so easy to see what effect it > will have on existing code. > > Is there a way we can conduct an experiment? And consider Graph-level > separately from Model-level? > > There is more room for manoeuvre at Graph-level. > > > >> --- A. Soroka The University of Virginia Library >> > > Andy > -- Paul Houle *Applying Schemas for Natural Language Processing, Distributed Systems, Classification and Text Mining and Data Lakes* (607) 539 6254 paul.houle on Skype [email protected] https://legalentityidentifier.info/lei/lookup <http://legalentityidentifier.info/lei/lookup>
