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
