[GitHub] [jena] ktreimann opened a new pull request #634: JENA-1781 update Thrift version

[GitBox]

ktreimann opened a new pull request #634: JENA-1781 update Thrift version
URL: https://github.com/apache/jena/pull/634
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Updated] (JENA-1782) Improve the informative printed form of the SHACL parse tree

[Andy Seaborne (Jira)]

 [ 
https://issues.apache.org/jira/browse/JENA-1782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andy Seaborne updated JENA-1782:

Summary: Improve the informative printed form of the SHACL parse tree  
(was: Improve the informnative printed form of the SHACL parse tree)

> Improve the informative printed form of the SHACL parse tree
> 
>
> Key: JENA-1782
> URL: https://issues.apache.org/jira/browse/JENA-1782
> Project: Apache Jena
>  Issue Type: Task
>  Components: SHACL
>Affects Versions: Jena 3.13.1
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Minor
> Fix For: Jena 3.14.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Doesn't helpfully print recurively sh:or, sh:and, sh:not shapes



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Assigned] (JENA-1781) Upgrade Thrift to version 0.13.0

[Andy Seaborne (Jira)]

 [ 
https://issues.apache.org/jira/browse/JENA-1781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andy Seaborne reassigned JENA-1781:
---

Assignee: Andy Seaborne

> Upgrade Thrift to version 0.13.0
> 
>
> Key: JENA-1781
> URL: https://issues.apache.org/jira/browse/JENA-1781
> Project: Apache Jena
>  Issue Type: Dependency upgrade
>  Components: ARQ, OSGi
>Reporter: Ken Treimann
>Assignee: Andy Seaborne
>Priority: Major
>
> OWASP Dependency Check identifies Thrift version 0.12.0 as having the 
> following vulnerabilites:
> [CVE-2019-0205|https://nvd.nist.gov/vuln/detail/CVE-2019-0205|https://nvd.nist.gov/vuln/detail/CVE-2019-0210]
> [CVE-2019-0210|https://nvd.nist.gov/vuln/detail/CVE-2019-0210]
> According to 
> [CASSANDRA-15420|https://issues.apache.org/jira/browse/CASSANDRA-15420], this 
> was partially fixed in version 0.11.0, but it still gets flagged as 
> vulnerable.  [This 
> message|http://mail-archives.apache.org/mod_mbox/thrift-dev/201910.mbox/%3CVI1PR0101MB2142E0EA19F582429C3AEBCBB1920%40VI1PR0101MB2142.eurprd01.prod.exchangelabs.com%3E]
>  from the thrift-dev mailing list states that the mitigation is to upgrade to 
> version 0.13.0.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [jena] afs opened a new pull request #633: JENA-1782: Better SHACL parse tree printing

[GitBox]

afs opened a new pull request #633: JENA-1782: Better SHACL parse tree printing
URL: https://github.com/apache/jena/pull/633
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Created] (JENA-1782) Improve the informnative printed form of the SHACL parse tree

[Andy Seaborne (Jira)]

Andy Seaborne created JENA-1782:
---

 Summary: Improve the informnative printed form of the SHACL parse 
tree
 Key: JENA-1782
 URL: https://issues.apache.org/jira/browse/JENA-1782
 Project: Apache Jena
  Issue Type: Task
  Components: SHACL
Affects Versions: Jena 3.13.1
Reporter: Andy Seaborne
Assignee: Andy Seaborne
 Fix For: Jena 3.14.0


Doesn't helpfully print recurively sh:or, sh:and, sh:not shapes



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (JENA-1781) Upgrade Thrift to version 0.13.0

[Ken Treimann (Jira)]

 [ 
https://issues.apache.org/jira/browse/JENA-1781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ken Treimann updated JENA-1781:
---
Description: 
OWASP Dependency Check identifies Thrift version 0.12.0 as having the following 
vulnerabilites:

[CVE-2019-0205|https://nvd.nist.gov/vuln/detail/CVE-2019-0205|https://nvd.nist.gov/vuln/detail/CVE-2019-0210]

[CVE-2019-0210|https://nvd.nist.gov/vuln/detail/CVE-2019-0210]

According to 
[CASSANDRA-15420|https://issues.apache.org/jira/browse/CASSANDRA-15420], this 
was partially fixed in version 0.11.0, but it still gets flagged as vulnerable. 
 [This 
message|http://mail-archives.apache.org/mod_mbox/thrift-dev/201910.mbox/%3CVI1PR0101MB2142E0EA19F582429C3AEBCBB1920%40VI1PR0101MB2142.eurprd01.prod.exchangelabs.com%3E]
 from the thrift-dev mailing list states that the mitigation is to upgrade to 
version 0.13.0.

  was:
OWASP Dependency Check identifies Thrift version 0.12.0 as having the following 
vulnerabilites:

[CVE-2019-0205|[https://nvd.nist.gov/vuln/detail/CVE-2019-0205|https://nvd.nist.gov/vuln/detail/CVE-2019-0210]]

[CVE-2019-0210|[https://nvd.nist.gov/vuln/detail/CVE-2019-0210]]

According to 
[CASSANDRA-15420|https://issues.apache.org/jira/browse/CASSANDRA-15420], this 
was partially fixed in version 0.11.0, but it still gets flagged as vulnerable. 
 [This 
message|[http://mail-archives.apache.org/mod_mbox/thrift-dev/201910.mbox/%3CVI1PR0101MB2142E0EA19F582429C3AEBCBB1920%40VI1PR0101MB2142.eurprd01.prod.exchangelabs.com%3E]]
 from the thrift-dev mailing list states that the mitigation is to upgrade to 
version 0.13.0.


> Upgrade Thrift to version 0.13.0
> 
>
> Key: JENA-1781
> URL: https://issues.apache.org/jira/browse/JENA-1781
> Project: Apache Jena
>  Issue Type: Dependency upgrade
>  Components: ARQ, OSGi
>Reporter: Ken Treimann
>Priority: Major
>
> OWASP Dependency Check identifies Thrift version 0.12.0 as having the 
> following vulnerabilites:
> [CVE-2019-0205|https://nvd.nist.gov/vuln/detail/CVE-2019-0205|https://nvd.nist.gov/vuln/detail/CVE-2019-0210]
> [CVE-2019-0210|https://nvd.nist.gov/vuln/detail/CVE-2019-0210]
> According to 
> [CASSANDRA-15420|https://issues.apache.org/jira/browse/CASSANDRA-15420], this 
> was partially fixed in version 0.11.0, but it still gets flagged as 
> vulnerable.  [This 
> message|http://mail-archives.apache.org/mod_mbox/thrift-dev/201910.mbox/%3CVI1PR0101MB2142E0EA19F582429C3AEBCBB1920%40VI1PR0101MB2142.eurprd01.prod.exchangelabs.com%3E]
>  from the thrift-dev mailing list states that the mitigation is to upgrade to 
> version 0.13.0.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (JENA-1781) Upgrade Thrift to version 0.13.0

[Ken Treimann (Jira)]

Ken Treimann created JENA-1781:
--

 Summary: Upgrade Thrift to version 0.13.0
 Key: JENA-1781
 URL: https://issues.apache.org/jira/browse/JENA-1781
 Project: Apache Jena
  Issue Type: Dependency upgrade
  Components: ARQ, OSGi
Reporter: Ken Treimann


OWASP Dependency Check identifies Thrift version 0.12.0 as having the following 
vulnerabilites:

[CVE-2019-0205|[https://nvd.nist.gov/vuln/detail/CVE-2019-0205|https://nvd.nist.gov/vuln/detail/CVE-2019-0210]]

[CVE-2019-0210|[https://nvd.nist.gov/vuln/detail/CVE-2019-0210]]

According to 
[CASSANDRA-15420|https://issues.apache.org/jira/browse/CASSANDRA-15420], this 
was partially fixed in version 0.11.0, but it still gets flagged as vulnerable. 
 [This 
message|[http://mail-archives.apache.org/mod_mbox/thrift-dev/201910.mbox/%3CVI1PR0101MB2142E0EA19F582429C3AEBCBB1920%40VI1PR0101MB2142.eurprd01.prod.exchangelabs.com%3E]]
 from the thrift-dev mailing list states that the mitigation is to upgrade to 
version 0.13.0.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: [java runtime] Re: Jena next

[ajs6f]

I'm not sure how unusually slow Bruno's $work is. It's the same where I am
and I know of plenty of other places in academia or government that look
similar schedule-wise.

To be clear, I am not arguing for Java 8 beyond Jena 3-- instead (I think)
I'm agreeing with Bruno that we might want to think about 11 as a good
compromise between all the good new language features becoming available
and getting solid uptake.

That having been said, we're at the beginning of a long journey and things
may well look different by the time we've actually scoped 4.

ajs6f

On Tue, Nov 19, 2019, 8:38 AM Andy Seaborne  wrote:

>
>
> On 16/11/2019 23:55, Bruno P. Kinoshita wrote:
> >> What perspectives do other people have on the landscape?
> > My company is pretty slow in updating its stack. They have Java8 only
> now (and an isolated pod with java 5 or 6 for a legacy app I think). Not
> aware of any java9+ yet.
> > I think for Jena 4 we could go with Java LTS os LTS-next (assuming Jena4
> may take a while to be ready)?
> > Bruno
>
> So the real question is whether they would use a Java11 runtime - and
> for security reasons updating the JVM is a good idea (tm) - even if its
> running older code.
>
> That's what I am seeing - Java11 JVM for Java8 apps especially when
> deploying a new installation. The standard IT dept recipe is for Java11
> so it just happens that way.
>
>  Andy
>
> >
> > Sent from Yahoo Mail on Android
> >
> >On Sun, 17 Nov 2019 at 10:41, Andy Seaborne wrote:
> >
> > On 14/11/2019 20:08, Aaron Coburn wrote:
> >> I would be very interested in discussing the high level Java API and
> how it
> >> could be simplified.
> >
> > Let's take API discussion to [API] and not loose the other points.
> >
> >> It might also be worthwhile to look into the overall package/jar
> structure.
> >> This will help for both OSGi and JPMS support.
> >
> > Yes.  The package structure is a current impedance.
> >
> >> Regarding the Java14/JPMS target, I assume this means that the Jena code
> >> can be compiled and run on a Java14 environment and/or used on the
> module
> >> path in a JPMS-enabled application (and *not* that all downstream
> >> applications must use one of the newer Java runtimes). That is, would
> the
> >> compiler target and source still be Java8?
> >
> > Actually, I was thinking Java14 APIs (var type inference improvements;
> > Java9 has Http/2; Java12,13 Switch Expressions;  java14 NVM
> > MappedByteBuffer improvemnts) and language changes - so a Java14 runtime
> > is required.
> >
> > Modules would not be required of applications, and mixed JavaOld/Java14
> > code can be run on a Java14 JVM.
> >
> > This is something we need to agree on first.
> >
> > If we going to move from Java8, we might as well jump to Java14.
> >
> > Jena3 remains for some overlap period.
> >
> > I think the Java version factor is changed by the slow demise of
> > multi-application platforms (e.g. Tomcat + multiple WAR files).
> > Container and microservices isolate the Java choice.
> >
> > Java8 EOL is September 2023 (End of free public updates by AdoptOpenJDK)
> > which is the same as Java11.
> >
> > What perspectives do other people have on the landscape?
> >
> >  Andy
> >
> >>
> >> Cheers,
> >> Aaron
> >>
> >> On Wed, 13 Nov 2019 at 14:18, Andy Seaborne  wrote:
> >>
> >>> I'd like to start a discussion on where the project might go longer
> term.
> >>>
> >>> This can be specific areas, overall design, about project processes,
> >>> anything.
> >>>
> >>> If we are going to do a major change, Jena4, what preparation for that
> >>> can be done? (e.g. deprecation and signalling in Jena3, before the
> >>> change happens).
> >>>
> >>> Realistically, Jena4 means having Jena3 and Jena4 in parallel. Jena4
> >>> need not be that big - we can have Jena5 etc.
> >>>
> >>> I'll put some technical points in a separate email.
> >>>
> >>> I would put on the list:
> >>>
> >>> * How has the world changed? What should the project produce?
> >>> * Target audience: for developers of Jena, while Jena3 is for users.
> >>> * Target: Java14, JPMS.
> >>> * Clear-up not easily done with perfect compatibility.
> >>> * Simpler. There are APIs and packages entangled due to history.
> >>>
> >>> To the lurkers :-)
> >>>
> >>> Feedback and specific feature requests are welcome. But before you "go
> >>> shopping", you may wish to factor in that every feature needs effort to
> >>> do it. The better place to be is that an application can get what it
> >>> needs to do, not whether the Jena system has every feature built-in.
> >>>
> >>>Andy
> >>>
> >>
> >
> >
>

Re: Jena next (AFS)

[ajs6f]

No problem! Streams and Iterators have confused me myself, but luckily Andy
and other folks helped straighten me out.

Andy, you've given a nice list of potential discussions and others have as
well. My meta-question is when do we want to switch to tickets for this
process? I don't want to smother discussion in process, but I find it very
hard to follow a multithreaded discussion over email and I much prefer
breaking things out early to more specifics.

Shall I start capturing (or trying to) ideas, or is it too soon?

ajs6f

On Tue, Nov 19, 2019, 11:49 AM Bögershausen, Merlin Michael <
merlin.boegershau...@rwth-aachen.de> wrote:

> Seems like I've got the wrong feeling from early messages, revisited Andys
> Post missed the "additional provide" part, sorry.
>
> Am 19.11.2019 16:48 schrieb "A. Soroka" :
> I think there may be some confusion here about Streams and Iterators.
> Streams are not and were never intended to be a replacement for or
> equivalent to Iterators. Iterators are a source of elements. There is no
> further complexity. Streams, on the other hand, are pipelines of
> computation which do not begin flowing until a terminal operation is called
> and then the data flows through the pipe without further action from the
> caller.
>
> We should not even consider replacing Iterators with Streams and I did not
> hear anyone suggest it. The suggestion I heard (and which I thoroughly
> support) is to offer Streams alongside Iterators for their intended
> purpose; pipelining computations.
>
> For example, consider a dataset backed by a remote SPARQL connection.
> Suppose stream() is called on a graph from this dataset, and suppose
> limit() is called on that Stream. Then in the right conditions a smart
> implementation could push that limit upstream to become a LIMIT in the
> SPARQL being sent over the wire. That's the real value of all those methods
> on Stream. They aren't merely for developer convenience. A library like our
> Iter would do for that. They are there to provide opportunities to classify
> and manage the computations being pipelined.
>
> So Stream is very useful for its purpose, but not for Iterator's purpose.
> As for crossing module boundaries, I haven't seen any problems with that
> and I'm not sure what the objection actually is. In fact, refusing to
> expose
> Streams at APIs seems to make the whole thing rather pointless.
>
> ajs6f
>
>
> On Tue, Nov 19, 2019, 10:06 AM Merlin Bögershausen <
> merlin.boegershau...@rwth-aachen.de> wrote:
>
> > Hi,
> >
> > To the Stream discussion: Streams should not be passed beyond module
> > borders. In my personal view not even beyond scopes, because the
> > exceptions thrown by an already terminated stream can be misleading.
> > Every user can feel free to use the StreamSupport class whenever the
> > application code uses streams.
> >
> > Another thing, I would like to see a graph view inside Fuseki UI, where
> > the triples are visualized like in
> > 
> > I use such visualization whenever I explain the usage of our graph data
> > model to my colleagues, whenever they have problems to develop SPARQL
> > queries. Also, I feel that it would help our support team to see why
> > the system performs unexpected steps.
> >
> > Merlin
> >
> >
>
>

Re: Jena next (AFS)

[Bögershausen , Merlin Michael]

Seems like I've got the wrong feeling from early messages, revisited Andys Post 
missed the "additional provide" part, sorry.

Am 19.11.2019 16:48 schrieb "A. Soroka" :
I think there may be some confusion here about Streams and Iterators.
Streams are not and were never intended to be a replacement for or
equivalent to Iterators. Iterators are a source of elements. There is no
further complexity. Streams, on the other hand, are pipelines of
computation which do not begin flowing until a terminal operation is called
and then the data flows through the pipe without further action from the
caller.

We should not even consider replacing Iterators with Streams and I did not
hear anyone suggest it. The suggestion I heard (and which I thoroughly
support) is to offer Streams alongside Iterators for their intended
purpose; pipelining computations.

For example, consider a dataset backed by a remote SPARQL connection.
Suppose stream() is called on a graph from this dataset, and suppose
limit() is called on that Stream. Then in the right conditions a smart
implementation could push that limit upstream to become a LIMIT in the
SPARQL being sent over the wire. That's the real value of all those methods
on Stream. They aren't merely for developer convenience. A library like our
Iter would do for that. They are there to provide opportunities to classify
and manage the computations being pipelined.

So Stream is very useful for its purpose, but not for Iterator's purpose.
As for crossing module boundaries, I haven't seen any problems with that
and I'm not sure what the objection actually is. In fact, refusing to expose
Streams at APIs seems to make the whole thing rather pointless.

ajs6f


On Tue, Nov 19, 2019, 10:06 AM Merlin Bögershausen <
merlin.boegershau...@rwth-aachen.de> wrote:

> Hi,
>
> To the Stream discussion: Streams should not be passed beyond module
> borders. In my personal view not even beyond scopes, because the
> exceptions thrown by an already terminated stream can be misleading.
> Every user can feel free to use the StreamSupport class whenever the
> application code uses streams.
>
> Another thing, I would like to see a graph view inside Fuseki UI, where
> the triples are visualized like in
> 
> I use such visualization whenever I explain the usage of our graph data
> model to my colleagues, whenever they have problems to develop SPARQL
> queries. Also, I feel that it would help our support team to see why
> the system performs unexpected steps.
>
> Merlin
>
>

Re: Jena next (AFS)

[A. Soroka]

I think there may be some confusion here about Streams and Iterators.
Streams are not and were never intended to be a replacement for or
equivalent to Iterators. Iterators are a source of elements. There is no
further complexity. Streams, on the other hand, are pipelines of
computation which do not begin flowing until a terminal operation is called
and then the data flows through the pipe without further action from the
caller.

We should not even consider replacing Iterators with Streams and I did not
hear anyone suggest it. The suggestion I heard (and which I thoroughly
support) is to offer Streams alongside Iterators for their intended
purpose; pipelining computations.

For example, consider a dataset backed by a remote SPARQL connection.
Suppose stream() is called on a graph from this dataset, and suppose
limit() is called on that Stream. Then in the right conditions a smart
implementation could push that limit upstream to become a LIMIT in the
SPARQL being sent over the wire. That's the real value of all those methods
on Stream. They aren't merely for developer convenience. A library like our
Iter would do for that. They are there to provide opportunities to classify
and manage the computations being pipelined.

So Stream is very useful for its purpose, but not for Iterator's purpose.
As for crossing module boundaries, I haven't seen any problems with that
and I'm not sure what the objection actually is. In fact, refusing to expose
Streams at APIs seems to make the whole thing rather pointless.

ajs6f


On Tue, Nov 19, 2019, 10:06 AM Merlin Bögershausen <
merlin.boegershau...@rwth-aachen.de> wrote:

> Hi,
>
> To the Stream discussion: Streams should not be passed beyond module
> borders. In my personal view not even beyond scopes, because the
> exceptions thrown by an already terminated stream can be misleading.
> Every user can feel free to use the StreamSupport class whenever the
> application code uses streams.
>
> Another thing, I would like to see a graph view inside Fuseki UI, where
> the triples are visualized like in
> 
> I use such visualization whenever I explain the usage of our graph data
> model to my colleagues, whenever they have problems to develop SPARQL
> queries. Also, I feel that it would help our support team to see why
> the system performs unexpected steps.
>
> Merlin
>
>

Re: Jena next (AFS)

[Merlin Bögershausen]

Hi,

To the Stream discussion: Streams should not be passed beyond module 
borders. In my personal view not even beyond scopes, because the 
exceptions thrown by an already terminated stream can be misleading.
Every user can feel free to use the StreamSupport class whenever the 
application code uses streams.


Another thing, I would like to see a graph view inside Fuseki UI, where 
the triples are visualized like in 

I use such visualization whenever I explain the usage of our graph data 
model to my colleagues, whenever they have problems to develop SPARQL 
queries. Also, I feel that it would help our support team to see why 
the system performs unexpected steps.


Merlin

Re: Jena next (AFS)

[Andy Seaborne]

On 17/11/2019 23:07, Claude Warren wrote:

I am a bit concerned about Streams.

I am working with some large scale streams from stored objects in another
project and keep coming up against stack overflow issues when attempting to
convert merge  them or convert from iterators.  Perhaps I have not done it
correctly but the iterator approach seems cleaner when you don't have or
can't have all the data in memory at once.


Interesting - have you got some stackOverflow links?

https://www.beyondjava.net/performance-java-8-lambdas
diucussed stream costs a bit (and interstign that lambda are not the issue)

Some of the speed reports of stream() are comparing streams with 
replacing loops - and that clearly is going to have am impact if the 
loop body is small, let along the fact the JIT probably knows how to do 
magic with plain loops.


Maybe, sometime, streams() will get JIT attention.



We might consider switching from the Jena specific iterators to
commons-collections4 (perhaps contributing some additions there).


Iter has nearly all the stream functions whereas commons-collections4 is 
a peckage of iterator classes that have to be nested.


So Iter can used like streams for nice code use (and is more complete 
than ExtendedIterator) and makes switching to streams easy, not zero but 
the syntax work needed is lessened.  In fact - that's a good goal for Iter.


(the missing bits are "collect" because Iter has Iter.toList and 
Iter.toSet - I do find the Stream.collect([Collectors.]toList) and 
absence of the direct form a bit odd - Adding Iter.collect is no bug 
deal thoiugh for completeness).


Andy



Claude

On Sun, Nov 17, 2019 at 5:34 PM Andy Seaborne  wrote:


This is a bit of a brain dump ...

== DatasetGraph

Graph Triple, Quad, DatasetGraph in a single API place.

== Graph - SPI

Graph - add a few navigation operations to make writing system directly
on Graph easier - though still not as rich as the Model API, and avoid
much of the object churn.

The operations are (not final names)

Graph.fwd(subject, predicate)
 -- return a single Node or null.
Graph.fwdList(subject, predicate)
 -- return a list of Nodes
Graph.fwdUnique(subject, predicate)
 -- return a single Node, exception if 0 or more than one.

Same for "bwk"


https://github.com/apache/jena/blob/master/jena-shacl/src/main/java/org/apache/jena/shacl/lib/G.java
is a library version of this that was helpful but adding a few
operations directly to graph

If the data is known to be good (SHACL), the application code can use
fwd()/bwk() without worrying about testing for zero or multiple predicates.

The reason for putting the basic oprations in the Graph interface and
not everything in a library is for potential efficiency. An impl may be
able to do a good job of fwd() and if that is the basis of graph
analytics efficiency matters long term, at least not to design it out.

== Assembler

The graph SPI additions is also motivated by assemblers.  Assemblers are
currently Model/Resource based but the important usage is in Fuseki - an
ideal goal is Fuseki works on Graph/Node.

Converting assemblers to Graph/Node does not look too burdensome and
with a wrapper layer we can hopefully include all the old tests to check
evolution.

== Graph - indexing

Currently, Graphs are term-indexed only or value-indexed, not both.

Graph should plain term-indexed. value-indexing, which can be calculated
on the fly, would be a separate higher-level concept.

This is motivated by scale and having the same behaviour on all graph.
At scale, canonicalizing the inputs is better than value-indexing.

"values" would only be in the Model API.

== Transactions

Unify the transaction approach (also changes Model) so complex
assemblages of graphs, and other things,  are transactional.

Remove graph transactions - replace by
org.apache.jena.sparql.core.Transactional.

Then graphs as views of datasets and also combinations of Transactionals
in single transaction (two DatasetGraph, or collection of Graphs (teh
assmebler case)) can be done.

== Events

Make events an intercepting wrapper, not built-in to Graph itself.
Add transaction lifecycle events.

== Streams - yes and no.

A Stream is several java objects so a potential cost
for a simple operations like Graph.contains() or find() or a few things
is not small.

Keep iterators, provide stream(s,p,o).

== Nodes

Lang tags - force to lower case.

Simplify - remove a layer of indirection. This relates to indexing.

Node_Literal - no LiteralLabels
Node_Blank - two longs or a string label, not using BlankNodeId

Investigate integrate nodes with ARQ's NodeValue.

== IRIs

jena-iri is general, powerful and hard to maintain.
Jena does not use all of it.
Jena needs a simpler, direct parser/checker.

https://github.com/afs/iri4ld

which is a parser in java with little copying. It parse URIs, and then
has a little on scheme specific rules for http(s), file and URN.

The various open source libraries

Re: [java runtime] Re: Jena next

[Andy Seaborne]

On 16/11/2019 23:55, Bruno P. Kinoshita wrote:

What perspectives do other people have on the landscape?

My company is pretty slow in updating its stack. They have Java8 only now (and 
an isolated pod with java 5 or 6 for a legacy app I think). Not aware of any 
java9+ yet.
I think for Jena 4 we could go with Java LTS os LTS-next (assuming Jena4 may 
take a while to be ready)?
Bruno


So the real question is whether they would use a Java11 runtime - and 
for security reasons updating the JVM is a good idea (tm) - even if its 
running older code.


That's what I am seeing - Java11 JVM for Java8 apps especially when 
deploying a new installation. The standard IT dept recipe is for Java11 
so it just happens that way.


Andy



Sent from Yahoo Mail on Android
  
   On Sun, 17 Nov 2019 at 10:41, Andy Seaborne wrote:


On 14/11/2019 20:08, Aaron Coburn wrote:

I would be very interested in discussing the high level Java API and how it
could be simplified.


Let's take API discussion to [API] and not loose the other points.


It might also be worthwhile to look into the overall package/jar structure.
This will help for both OSGi and JPMS support.


Yes.  The package structure is a current impedance.


Regarding the Java14/JPMS target, I assume this means that the Jena code
can be compiled and run on a Java14 environment and/or used on the module
path in a JPMS-enabled application (and *not* that all downstream
applications must use one of the newer Java runtimes). That is, would the
compiler target and source still be Java8?


Actually, I was thinking Java14 APIs (var type inference improvements;
Java9 has Http/2; Java12,13 Switch Expressions;  java14 NVM
MappedByteBuffer improvemnts) and language changes - so a Java14 runtime
is required.

Modules would not be required of applications, and mixed JavaOld/Java14
code can be run on a Java14 JVM.

This is something we need to agree on first.

If we going to move from Java8, we might as well jump to Java14.

Jena3 remains for some overlap period.

I think the Java version factor is changed by the slow demise of
multi-application platforms (e.g. Tomcat + multiple WAR files).
Container and microservices isolate the Java choice.

Java8 EOL is September 2023 (End of free public updates by AdoptOpenJDK)
which is the same as Java11.

What perspectives do other people have on the landscape?

     Andy



Cheers,
Aaron

On Wed, 13 Nov 2019 at 14:18, Andy Seaborne  wrote:


I'd like to start a discussion on where the project might go longer term.

This can be specific areas, overall design, about project processes,
anything.

If we are going to do a major change, Jena4, what preparation for that
can be done? (e.g. deprecation and signalling in Jena3, before the
change happens).

Realistically, Jena4 means having Jena3 and Jena4 in parallel. Jena4
need not be that big - we can have Jena5 etc.

I'll put some technical points in a separate email.

I would put on the list:

* How has the world changed? What should the project produce?
* Target audience: for developers of Jena, while Jena3 is for users.
* Target: Java14, JPMS.
* Clear-up not easily done with perfect compatibility.
* Simpler. There are APIs and packages entangled due to history.

To the lurkers :-)

Feedback and specific feature requests are welcome. But before you "go
shopping", you may wish to factor in that every feature needs effort to
do it. The better place to be is that an application can get what it
needs to do, not whether the Jena system has every feature built-in.

       Andy