Java 8 Streams Was: What can be removed/simplified ?

a RDFList (or an iterator on one) is returned . Claude On Fri, May 1, 2015 at 5:12 PM, aj...@virginia.edu aj...@virginia.edu 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

Re: What can be removed/simplified ?

. I you want I can send you the source to test your implementation with. This will mean adding junit-contracts as a dependency for your tests. Claude On Fri, May 1, 2015 at 5:26 PM, aj...@virginia.edu aj...@virginia.edu wrote: Yes, in that case, the change was no more than extends

Re: Java 8 Streams Was: What can be removed/simplified ?

free to submit an issue to https://issues.apache.org/jira/browse/FUNCTOR or ping the commons dev mailing list :-) All the bestBruno From: aj...@virginia.edu aj...@virginia.edu To: dev@jena.apache.org Sent: Saturday, May 2, 2015 6:05 AM Subject: Java 8 Streams Was: What can

Re: Java 8 Streams Was: What can be removed/simplified ?

and Property types but you need to write code to create these things to put them in all the slots and it starts to obscure the simplicity of what is going on. On Mon, May 4, 2015 at 11:50 AM, aj...@virginia.edu aj...@virginia.edu wrote: Thank you for the heads up: I was unaware of Commons

Re: What can be removed/simplified ?

. Claude On Fri, May 1, 2015 at 4:53 PM, aj...@virginia.edu aj...@virginia.edu 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

Re: What can be removed/simplified ?

PM, aj...@virginia.edu aj...@virginia.edu 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

Re: What can be removed/simplified ?

Great! Thank you. Would Jena be similarly interested in trying to migrate org.apache.jena.util.iterator.Filter to java.util.function.Predicate? --- A. Soroka The University of Virginia Library On May 1, 2015, at 3:32 AM, Andy Seaborne a...@apache.org wrote: On 30/04/15 17:11, aj

Re: What can be removed/simplified ?

I'm a long-time user of Jena, but entirely new to its internals, so this may be a very off-the-mark opinion, but perhaps org.apache.jena.util.iterator.Map1 could be swapped out for java.util.function.Function? --- A. Soroka The University of Virginia Library On Apr 30, 2015, at 10:39 AM, Andy

Re: another clean up suggestion: dead code and its resuscitation

code. Also any commented code as well. We have a source control system, one can always look into the history to get that stuff. Using a field just makes it worse IMO... it'll never get removed if we do that. -Stephen On Thu, May 7, 2015 at 11:26 AM, A. Soroka aj...@virginia.edu wrote

Re: another clean up suggestion: dead code and its resuscitation

...@virginia.edu aj...@virginia.edu wrote: I'm building a PR [1] right now as a sort of think-piece to give us something concrete to look at. I'm building it up out of ONLY things that Eclipse/javac can determine are definitely impossible to execute or redundant or never used, including: - Private

Re: another clean up suggestion: dead code and its resuscitation

, May 8, 2015 at 3:54 AM, aj...@virginia.edu aj...@virginia.edu wrote: I'm building a PR [1] right now as a sort of think-piece to give us something concrete to look at. I'm building it up out of ONLY things that Eclipse/javac can determine are definitely impossible to execute or redundant

Re: another possible simplification

Okay, that makes sense, although in some ways it seems more like a rationale for keeping _an_ interface, rather than a rationale that Jena should have its _own_ interface. But keeping Guava types from leaking through makes sense. I will send a PR sometime soon with some Java 8 work in those

Re: Commons RDF

Wearing my Jena user's hat for a moment, this would be lovely and I would be happy to help with it. A project [1] on which I work persists RDF via some very complex mappings into and out of a JCR repository, and being able to stream it a little more gracefully would be a nice win for us. Those

code quality tools WAS: Code policies

and the web site if we decided to use 120 or any other number. We can probably leave some basic policies (no tabs, no unused imports, etc). WDYT? Bruno From: A. Soroka aj...@virginia.edu To: dev@jena.apache.org dev@jena.apache.org Sent: Wednesday, May 13, 2015 2:07 AM Subject

Re: [jira] [Created] (JENA-957) Review concurrency howto in the light of transactions.

So to be clear, part of the idea here is to boost the visibility of transactions, and one of the things that wants doing as part of that is to provide for copy-on-add-graph semantics for the in-memory dataset so that transactionality is coherent across such a dataset. Right now it instead is a

Re: Trouble Building Under Eclipse

central, which should only change when we upgrade Guava, in which case it could be re-enabled in the SNAPSHOT build or vote+released as a separate artifact (which might be slightly odd as it contains no Jena contributions beyond the package name) On 4 Jun 2015 14:33, aj...@virginia.edu aj

CLI libraries

In examining and discussing https://issues.apache.org/jira/browse/JENA-959, it seems to me (a Jena newbie!) that Jena's CLI action is built up in jena-core, in package jena.cmdline. If that is correct, and Jena has its own CLI code, wouldn't it be better to replace this with a modern CLI

Re: CLI libraries

, Andy Seaborne a...@apache.org wrote: On 08/06/15 15:47, aj...@virginia.edu wrote: In examining and discussing https://issues.apache.org/jira/browse/JENA-959, it seems to me (a Jena newbie!) that Jena's CLI action is built up in jena-core, in package jena.cmdline. If that is correct, and Jena

Re: TDB2

Is there some high level overview of Lizard/Mantis/TDB2 yet extant? Like the kind of thing we might see at a conference? In any event, thanks for working on this-- it's great to know that Jena will be able to cluster soon. --- A. Soroka The University of Virginia Library On Jun 8, 2015, at

Re: Trouble Building Under Eclipse

-guava does not mention com.google.guava:guava. Elephas picks up the Hadoop dependency. Andy On 08/06/15 14:26, aj...@virginia.edu wrote: I think the idea of breaking the shaded Guava artifact out of the main cycle is great. It's clearly not a subject of work under most

Re: [jira] [Created] (JENA-957) Review concurrency howto in the light of transactions.

On Jun 8, 2015, at 6:35 PM, Andy Seaborne a...@apache.org wrote: less - there is no transactionality across the contained graphs. (Model.graph transactions aren't connected to dataset transactions) Ah, glad I asked! {grin} As far as model-as-views-of-datasets: is it true that all that is

Re: CLI libraries

I don't see any actual references in the documentation to rdfcat. Perhaps it can be deprecated? --- A. Soroka The University of Virginia Library On Jun 8, 2015, at 11:24 AM, Andy Seaborne a...@apache.org wrote: People use rdfcat :-( but nowadays riot is better IMO (scale, speed, arguments,

Re: [jira] [Comment Edited] (JENA-966) LazyIterator

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

Re: [jira] [Commented] (JENA-966) LazyIterator

Right, I updated my comment right after I made it, when I noticed the difference. I shouldn't think it matters which one to keep. LazyIterator is a little shorter to write. :) There are a number of other Iterators (noted in the comments to that ticket) that seem to be depreciate-able. E.g.

Re: CLI libraries

that be the _only_ think rdfcat does in Jena 3. --- A. Soroka The University of Virginia Library On Jun 10, 2015, at 6:39 AM, Andy Seaborne a...@apache.org wrote: On 09/06/15 17:11, aj...@virginia.edu wrote: I don't see any actual references in the documentation to rdfcat. Perhaps it can

Re: [jira] [Commented] (JENA-966) LazyIterator

How about using a Java 8 SupplierIteratorT? That's pretty lazy. --- A. Soroka The University of Virginia Library On Jun 17, 2015, at 5:07 AM, Claude Warren cla...@xenei.com wrote: I wanted to use it in an application. Is there a replacement? On Wed, Jun 17, 2015 at 9:10 AM, Andy Seaborne

Re: Trouble Building Under Eclipse

a...@apache.org wrote: On 09/06/15 16:26, aj...@virginia.edu wrote: Okay, now I get why we're sticking with shading in Guava, at least for now (since this seems like the kind of problem that OSGi solves and hopefully Jigsaw will solve). Are there objections to ejecting shaded Guava from

Re: Trouble Building Under Eclipse

I have had this problem since I began tinkering. The only solution I have found is make sure that the jena-shaded-guava project is never open when any project that refers to types therein is open. This isn't much of a burden, and I suppose it has something to do with the Maven magic that is

Re: Fuskei and ETags

On Jun 29, 2015, at 9:33 AM, Claude Warren cla...@xenei.com wrote: If there were an ETag per dataset and a method on the dataset to force an ETag reset would this address the index issue in that the indexer could reset the ETag when it deemed appropriate? It might-- for that indexer. I would

Re: Fuskei and ETags

(); // to retrieve the current tag. Claude On Mon, Jun 29, 2015 at 2:50 PM, aj...@virginia.edu aj...@virginia.edu wrote: On Jun 29, 2015, at 9:33 AM, Claude Warren cla...@xenei.com wrote: If there were an ETag per dataset and a method on the dataset to force an ETag reset would

Re: CMS diff: Reviewing Contributions

Good point. (Speaking as someone who regularly has to be corrected about this {grin}.) --- A. Soroka The University of Virginia Library On Jun 29, 2015, at 12:57 PM, Andy Seaborne a...@apache.org wrote: Good comments - I've made some revisions to the page based on this input. It reminded

Re: Journaling DatasetGraph

is a ReentrantReadWriteLock + counting support to catch application errors). DatasetGraphWithRecord is relying on single-W for its own datastructures. Andy On 29/07/15 21:22, aj...@virginia.edu wrote: I'm not sure I understand this advice-- are you saying that because no DatasetGraph can be assumed

Re: Journaling DatasetGraph

, in practice, all DatasetGraphs _do_ support MR, there's no need to enforce it at the level of DatasetGraphWithRecord? --- A. Soroka The University of Virginia Library On Jul 29, 2015, at 4:14 PM, Andy Seaborne a...@apache.org wrote: On 27/07/15 18:06, aj...@virginia.edu wrote: Is there some

Re: Journaling DatasetGraph

). DatasetGraphWithRecord is relying on single-W for its own datastructures. Andy On 29/07/15 21:22, aj...@virginia.edu wrote: I'm not sure I understand this advice-- are you saying that because no DatasetGraph can be assumed to support MR, there isn't any point in trying to support MR

Re: RDFConnection

Is this a little bit like Sesame 4's new Repository helper type? Not totally the same thing, but similar in that it's bringing a lot of convenience together around the notion of dataset? http://rdf4j.org/doc/4/programming.docbook?view#Stream_based_querying_and_transaction_handling --- A.

Re: RDFConnection

). There's scope to add forms on top. void execSelect(Query query, ConsumerQuerySolution action) is one possibility. Andy On 04/08/15 16:14, aj...@virginia.edu wrote: Is this a little bit like Sesame 4's new Repository helper type? Not totally the same thing, but similar

Re: Journaling DatasetGraph

On Aug 4, 2015, at 4:32 PM, Andy Seaborne a...@apache.org wrote: On 03/08/15 17:13, aj...@virginia.edu wrote: I've made some emendations to (hopefully) fix this problem. In order to so do, I added a method to Lock itself to report the quality of an instance, simply as an enumeration. I had hoped

Re: RDFConnection

in several places (search for empty graphs in the SPARQL 1.1 update spec) and various SPARQL Updates behaviours may differ depending on whether the storage layer records the presence of empty graphs or not Rob On 05/08/2015 13:44, aj...@virginia.edu aj...@virginia.edu wrote: Just

Re: Journaling DatasetGraph

Thanks for the feedback, Andy! See comment in-line below. --- A. Soroka The University of Virginia Library On Jul 25, 2015, at 7:43 AM, Andy Seaborne a...@apache.org wrote: A first look - there's quite a lot to do with the release at the moment. Right, I don't expect anyone to get around to

Re: Journaling DatasetGraph

extending Quad. --- A. Soroka The University of Virginia Library On Jul 25, 2015, at 7:43 AM, Andy Seaborne a...@apache.org wrote: On 23/07/15 14:18, aj...@virginia.edu wrote: After a longish conversation with Andy Seaborne, I've worked up a simple journaling DatasetGraph wrapping implementation

Re: Iter vs. ExtendedIterator

Since I'm trying to get to an understanding from which I can write a PR with some new Javadocs for these type, let me try out the following: Iter should never be used for a return type or parameter type in the public contract of a class. It is only to be used inside implementation code and it

Journaling DatasetGraph

After a longish conversation with Andy Seaborne, I've worked up a simple journaling DatasetGraph wrapping implementation. The idea is to use journaling to support proper aborting behavior (which I believe this code does) and to add to that a semantic for DatasetGraph::addGraph that copies

Re: Iter vs. ExtendedIterator

Okay, so if I were writing some new code in a Jena module, and I needed to do some of the tasks for which these guys have facilities (e.g. filtering), how should I select a type to use? Should I only use ExtendedIterator's methods if the thing I already have in hand is an ExtendedIterator? Put

Re: JENA-624: Develop a new in-memory RDF Dataset implementation

Andy-- Thanks, these comments are really helpful! I've replied in-line in a few places to clarify or answer questions, or ask some of my own. {grin} --- A. Soroka The University of Virginia Library On Aug 27, 2015, at 5:35 AM, Andy Seaborne a...@apache.org wrote: 1) All-transactional action:

Re: JENA-624: Develop a new in-memory RDF Dataset implementation

On Aug 28, 2015, at 6:17 AM, Andy Seaborne a...@apache.org wrote: On 27/08/15 16:53, aj...@virginia.edu wrote: Andy-- Thanks, these comments are really helpful! I've replied in-line in a few places to clarify or answer questions, or ask some of my own. {grin} --- A. Soroka The University

Re: JENA-624: Develop a new in-memory RDF Dataset implementation

a...@apache.org wrote: On 28/08/15 12:22, aj...@virginia.edu wrote: In fact, this is why I tried (for a first try) a design with only one transaction committing at a time, which amounts to SW in terms of serializability, I thought. No :-( But I am allowing multiple writers to assemble changes

Re: JENA-624: Develop a new in-memory RDF Dataset implementation

an in-memory and a relational DB based version recently, but it was just a quick POC. Claude On Wed, Aug 26, 2015 at 3:27 PM, A. Soroka aj...@virginia.edu wrote: Hey, folks-- There hasn't been too much feedback on my proposal for a journaling DatasetGraph: https://github.com/ajs6f/jena

Re: JENA-624: "Develop a new in-memory RDF Dataset implementation"

I apologize if I am being thick here, but I don't understand how one goes about checking the potential match without some kind of covering resource against which to do that, something with a full representation of the graph. Can you elaborate on how to check the validity of the match? Thank

Re: JENA-624: "Develop a new in-memory RDF Dataset implementation"

ads - that's the way the >> world is going. >> >> So each quad is reduced to a >>> single bloom filter comprising 4 items (15-bytes). >>> >> >>Andy >> >> [*] even in memory, it might be worth allocating internal ids and work

Re: [] 201508 Release of 23 Clerezza modules

If this is a matter of "just a couple of lines in the manifest file" cannot a patch be created to do that in Jena itself? Are there inter-module dependency issues that make that difficult? --- A. Soroka The University of Virginia Library On Sep 10, 2015, at 11:49 AM, Reto Gmür

Re: Jena OSGi (was: [] 201508 Release of 23 Clerezza modules)

can then be used directly. The > > > > > > > > On 10 September 2015 at 22:50, Stian Soiland-Reyes <st...@apache.org> wrote: >> On 10 September 2015 at 18:13, aj...@virginia.edu <aj...@virginia.edu> wrote: >>> If this is a matter o

Re: 3rd party modifying Jena binaries. Re: [] 201508 Release of 23 Clerezza modules

Is it your impression that the "special OSGi spice" additions are something that Jena could reasonably adopt into normal builds? Then maybe they wouldn't feel the need to do this… --- A. Soroka The University of Virginia Library On Sep 9, 2015, at 4:06 PM, Andy Seaborne

Re: Jena system initialization

> > When a class is loaded, the is not run. That happens on first use. > Ah, this is what I did not understand correctly. Okay, no problem. IMHO JenaSystem.init is a step in the right direction and better way than > the current way initialization is done. > No argument here. What would be

Re: Maintenance branches

I think Claude introduced the idea of LTS releases, so I'm curious about whether he thinks that the audience for stability includes people who would use a "stable" series of the kind Osma describes, even without the Apache imprimatur. ajs6f > On Jan 24, 2017, at 2:57 PM, Andy Seaborne

Re: Maintenance branches

I've had some experience with protocols such as are described by Osma and I think that they have real value for (particularly for large) users and sites. And as he says, they can be automated. I would be willing to help with that. I would like to learn more about Apache infrastructure. That