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. 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.
- 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>.
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.
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.
---
A. Soroka
The University of Virginia Library
On May 1, 2015, at 12:19 PM, Claude Warren <[email protected]> wrote:
> An example is:
>
> org.apache.jena.security.utils.RDFListSecFilter
>
> Which filters results based on user access and is used whereever a RDFList
> (or an iterator on one) is returned .
>
> Claude
>
> On Fri, May 1, 2015 at 5:12 PM, [email protected] <[email protected]>
> wrote:
>
>> Oh, now I think I understand your point better.
>>
>> Yes, I have already trawled that code and worked over those reusable guys,
>> and yes, you will certainly still be able to combine and reuse Predicates
>> in the same way that you have used Filters. When I get this PR in, you can
>> see some examples of that.
>>
>> A Java 8 Predicate is just an interface that looks much like Jena's
>> Filter, which can benefit from the -> lamda syntax and which is designed to
>> fit into the Java 8 language APIs (e.g. for use with Streams).
>>
>> ---
>> A. Soroka
>> The University of Virginia Library
>>
>> On May 1, 2015, at 12:07 PM, Claude Warren <[email protected]> wrote:
>>
>>> We have a number of places where Filter objects are created and reused
>>> (usueally due to complexity or to reduce the code footprint in terms of
>>> debugging). Will it still be possible to define these complex filters
>> and
>>> use them in multiple places.
>>>
>>> The permissions system does this in that it creates a filter for RDFNodes
>>> and then applies them to the 3 elements in a triple to create a single
>>> filter for triples.
>>>
>>> There are several cases like this.
>>>
>>> I will have to look at the permissions code to find a concrete example,
>> but
>>> I think this is the case.
>>>
>>> Claude
>>>
>>> On Fri, May 1, 2015 at 4:53 PM, [email protected] <[email protected]>
>>> wrote:
>>>
>>>>> As for the Filter implementation..... will that be transparant to
>> filter
>>>> implementations? I assume so.
>>>>
>>>> I think this was in response to my question about Filter?
>>>>
>>>> If you mean that things that currently implement Filter (outside of
>> Jena's
>>>> own code) will not be greatly affected, then yes, so I would hope. I
>> will
>>>> @Deprecated Filter and its methods, but that seems to me to be all that
>> is
>>>> needed for this first step.
>>>>
>>>> I should have a PR with this later today, when you can observe some real
>>>> code and give me feedback.
>>>>
>>>> ---
>>>> A. Soroka
>>>> The University of Virginia Library
>>>>
>>>> On May 1, 2015, at 11:47 AM, Claude Warren <[email protected]> wrote:
>>>>
>>>>> I don't see any reason not to remove the Node functions.
>>>>>
>>>>> As for the Filter implementation..... will that be transparant to
>> filter
>>>>> implementations? I assume so.
>>>>>
>>>>> On Fri, May 1, 2015 at 4:16 PM, Andy Seaborne <[email protected]> wrote:
>>>>>
>>>>>> (mainly for Claude - I did check jena-pemissions and didn't see any
>>>> usage)
>>>>>>
>>>>>> There are a bunch of deprecated statics in Node (the correct way is to
>>>> use
>>>>>> NodeFactory)
>>>>>>
>>>>>> Node.createAnon()
>>>>>> Node.createAnon(AnonId)
>>>>>> Node.createLiteral(LiteralLabel)
>>>>>> Node.createURI(String)
>>>>>> Node.createVariable(String)
>>>>>> Node.createLiteral(String)
>>>>>> Node.createLiteral(String, String, boolean)
>>>>>> Node.createLiteral(String, String, RDFDatatype)
>>>>>> Node.createLiteral(String, RDFDatatype)
>>>>>> Node.createUncachedLiteral(Object, String, RDFDatatype)
>>>>>> Node.createUncachedLiteral(Object, RDFDatatype)
>>>>>>
>>>>>> It looks like they are not used by the jena codebase and are there for
>>>>>> compatibility only.
>>>>>>
>>>>>> Any reason not to remove them?
>>>>>>
>>>>>> Andy
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> I like: Like Like - The likeliest place on the web
>>>>> <http://like-like.xenei.com>
>>>>> LinkedIn: http://www.linkedin.com/in/claudewarren
>>>>
>>>>
>>>
>>>
>>> --
>>> I like: Like Like - The likeliest place on the web
>>> <http://like-like.xenei.com>
>>> LinkedIn: http://www.linkedin.com/in/claudewarren
>>
>>
>
>
> --
> I like: Like Like - The likeliest place on the web
> <http://like-like.xenei.com>
> LinkedIn: http://www.linkedin.com/in/claudewarren
