Progress on 1391 hasn't been blocked on a new API, not at all. Just taking a good while because of general busy-ness. I was able to write some more tests over the last few days and I think I should be able to finish up very early in January. You can track progress at:
https://github.com/apache/jena/compare/master...ajs6f:JENA-1391 ajs6f > On Dec 17, 2017, at 8:15 PM, Adam Jacobs <[email protected]> wrote: > > I just want to mention that it was not my intent to derail progress on > Jena-1391 (https://issues.apache.org/jira/browse/JENA-1391) by raising the > issue of immutability, > particularly if immutability would be implemented via a new API. I don't > think it should be considered a blocker to that story. Apologies if I threw a > wrench into the plan. > > > ________________________________________ > From: ajs6f <[email protected]> > Sent: Wednesday, December 13, 2017 10:39 AM > To: [email protected] > Subject: potential new API Was: Immutability > > Yes, the SPI is likely fine, or we will find out otherwise if we try a new > API. :) > > A new API is clearly no small thing. I suppose one way to approach the thing > would be to look at what Clerezza and RDF4J 4 and Commons RDF have come up > with, what worked and what didn't, and then bring in our own use cases and > ideas... > > The two "asks" I've heard recently from Jena users are: immutability and > Streams. I'm guessing there are others. I would like to take advantage of > Optional for some of the attributes of a node (e.g. return the lang of a > literal as Optional). > > Other thoughts? It's fun to make wish lists at the end of the year. :grin: > > ajs6f > >> On Nov 16, 2017, at 11:47 AM, Andy Seaborne <[email protected]> wrote: >> >> Yes, I think it is best done as a new API. >> >> Modifications to the existing one are likely to run into problems somewhere >> and given the number of users, and the change over time on upgrades, having >> compatibility matters as does gradual migration >> >> A complicates case: Dataset.getModel(String) returns a model. No idea >> whether it is immutable or not or how it will be used. Assigning to a >> ImmutableModel does not guaratee anything - it helps the caller not make >> mistakes but the model is not immutable. Some code calling getModel can >> change it. And the union model isn't immutable! - it's a dynamic union and >> any name graph change will be reflected. The world is multithreaded. >> >> But the main reason for a new API is that this is just one of several >> features to include so to make it a success these different features need to >> come together into one *agreed* design. >> >> The good news is that it can target the SPI. >> (I see no value in changing the SPI for this - that's not it's role) >> >> ARQ's API is really very small. A design that took a dataset+model view of >> the world would be a good thing. >> >> Andy >> >> See also commons-rdf. >> That is RDF 1.1 compliant >> >> On 15/11/17 15:52, [email protected] wrote: >>> So it seems to me that if we want to introduce immutable types, we might >>> want to do that in the context of a completely new API. The use of the Java >>> 8 Streams API is also something that has been mooted as something that >>> might merit a new Jena API. (Instead of mixing things up in the current >>> one.) >>> I'm not sure how that plays out with ARQ, though. We would want people to >>> be able to use the new types with ARQ without much difficulty. >
