Fwd: Jena dependencies on JDK-Internal APIs
Forwarded Message Subject:Jena dependencies on JDK-Internal APIs Date: Mon, 15 Jun 2015 09:09:27 +0100 From: Rory O'Donnell rory.odonn...@oracle.com To: a...@apache.org CC: Hi Andy, My name is Rory O'Donnell, I am the OpenJDK Quality Group Lead. I'm contacting you because your open source project seems to be a very popular dependency for other open source projects. As part of the preparations for JDK 9, Oracle’s engineers have been analyzing open source projects like yours to understand usage. One area of concern involves identifying compatibility problems, such as reliance on JDK-internal APIs. Our engineers have already prepared guidance on migrating some of the more common usage patterns of JDK-internal APIs to supported public interfaces. The list is on the OpenJDK wiki [0]. As part of the ongoing development of JDK 9, I would like to inquire about your usage of JDK-internal APIs and to encourage migration towards supported Java APIs if necessary. The first step is to identify if your application(s) is leveraging internal APIs. /Step 1: Download JDeps. / Just download a preview release of JDK8(JDeps Download https://jdk8.java.net/download.html). You do not need to actually test or run your application on JDK8. JDeps(Docs http://docs.oracle.com/javase/8/docs/technotes/tools/unix/jdeps.html) looks through JAR files and identifies which JAR files use internal APIs and then lists those APIs. /Step 2: To run JDeps against an application/. The command looks like: jdk8/bin/jdeps -P -jdkinternals *.jar your-application.jdeps.txt The output inside your-application.jdeps.txt will look like: your.package (Filename.jar) - com.sun.corba.seJDK internal API (rt.jar) _3rd party library using Internal APIs:_ If your analysis uncovers a third-party component that you rely on, you can contact the provider and let them know of the upcoming changes. You can then either work with the provider to get an updated library that won't rely on Internal APIs, or you can find an alternative provider for the capabilities that the offending library provides. _Dynamic use of Internal APIs:_ JDeps can not detect dynamic use of internal APIs, for example through reflection, service loaders and similar mechanisms. Rgds,Rory [0] https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland
Re: [ANN] GSoC 2015 Accepts a Student Project for Jena
Hi, I just opened 2 new threads. Your comments are welcome! regards, Qihong On Mon, Jun 15, 2015 at 4:45 PM, Rob Vesse rve...@dotnetrdf.org wrote: Folks Could you please either start new threads of change the subject line appropriately for future discussions on this The generic subject line makes it hard when catching up with emails to see at a glance what this thread is about Thanks, Rob On 14/06/2015 12:28, Andy Seaborne a...@apache.org wrote: Hi, Would it be possible to add new methods constructors to Template.java while leaving the existing methods/constructors in-place (reimplemented in Template; that does not affect the SPARQL 1.0 parser). Then the source code for the SPARQL 1.0 parser does not need change. The main (and only, I think) use from the SPARQL 1.0 grammar is the constructor new Template(basic graph pattern). So if there is a constructor to match that, the generated source code for SPARQL 1.0 does not need to change (it may need to recompiled but that's happening anyway). Another constructor can take a QuadPattern. getTriple/getBGP only returns the default graph related triples. A new getQuads returns everything. Is there some code on github for the changes to Template to look at? If you drop some links here, I'll try to find some time to take a look soon. Don't worry too much at this stage - If SPARQL 1.0 gets in the way too much of you making progress, then delete it from your code (but note the fact so we can be careful when merging pull requests later!!) Andy On 14/06/15 05:16, Ying Jiang wrote: Hi Qihong, It doesn't matter. For a temperate solution, just change the code of SPARQL_10 manually to make the compiling work. Please don't wait the answers from the list. Many of the questions do not stop you from coding. We would be glad if you can deliver your code as soon/often as possible. Best regards, Ying Jiang On Fri, Jun 12, 2015 at 9:54 AM, Qihong Lin confidence@gmail.com wrote: Hi, If the checksum and grammar script is OK, I'd like to continue coding. However, the grammar script only generates ARQ and SPARQL_11, without touching SPARQL_10. If I change the code of, e.g. Template [1], it will affect SPARQL_10. Shall I modify the code of SPARQL_10 manually, change the sparql_10.jj grammar manually, or re-generate SPARQL_10 with the grammar script (and how?) ? regards, Qihong [1] https://github.com/confidencesun/jena/blob/master/jena-arq/src/main/java /org/apache/jena/sparql/syntax/Template.java On Fri, Jun 12, 2015 at 12:10 AM, Ying Jiang jpz6311...@gmail.com wrote: Hi Qihong, Have you modified any files? If the grammar file is identical, the checksum of each generated java class should be the same. Best regards, Ying Jiang On Mon, Jun 8, 2015 at 5:27 PM, Qihong Lin confidence@gmail.com wrote: Hi, The grammar has been modified for the problems you pointed out. I've tried to run grammar script to generate arq.jj, sparql_11.jj and their parser java classes, in cygwin with JavaCC 5.0. However the generated java classes are different from those in the code base: 1) ARQParser - the new generated one: public class ARQParser extends ARQParserBase implements ARQParserConstants - the old one in the code base: public class ARQParser extends ARQParserBase There's no such difference for SPARQLParser11 (both new and old ones have implements ...) 2) checksum for Token, ParseException, JavaCharStream and so on - the new generated one (Token.java): /* JavaCC - OriginalChecksum=335d1922781852977208d5cdca0fc164 (do not edit this line) */ - the old one in the code base (Token.java): /* JavaCC - OriginalChecksum=d9b4c8c9332fa3054a004615fdb22b89 (do not edit this line) */ The log from grammar script seems OK: $ ./grammar Process grammar -- sparql_11.jj Java Compiler Compiler Version 5.0 (Parser Generator) (type javacc with no arguments for help) Reading from file sparql_11.jj . . . File TokenMgrError.java does not exist. Will create one. File ParseException.java does not exist. Will create one. File Token.java does not exist. Will create one. File JavaCharStream.java does not exist. Will create one. Parser generated successfully. Create text form Java Compiler Compiler Version 5.0 (Documentation Generator Version 0.1.4) (type jjdoc with no arguments for help) Reading from file sparql_11.jj . . . Grammar documentation generated successfully in sparql_11.txt Fixing Java warnings in TokenManager ... Fixing Java warnings in Token ... Fixing Java warnings in TokenMgrError ... Fixing Java warnings in SPARQLParser11 ... Done Process grammar -- arq.jj Java Compiler Compiler Version 5.0 (Parser Generator) (type javacc with no arguments for help) Reading from file arq.jj . . . File TokenMgrError.java does not exist. Will create one. File ParseException.java does not exist. Will create one. File Token.java does not exist. Will create
Re: [GSoC 2015 - JENA-491] JavaCC with master.jj
Qihong,
There is an ambiguity in the grammar if you make GRAPH optional.
See rule 'Quads'
Consider these two cases:
:s :p :o .
:z { :s1 :p1 :o1 } .
:s :p :o .
:z :q :o2 .
when the parser get to end of the triple in the default graph:
:s :p :o .
there are two ways forward: more triples (TriplesTemplate) and end of
the triples part, start of named graph.
It looks ahead one token and see :z and needs to decide whether the next
rule is more triples, the :z :q :o2 . case, or the end of the triples
for the default graph and the start of a named graph the :z { :s1 :p1
:o1 } . where it exists TriplesTemplate and moves on to QuadsNotTriples
If GRAPH then the entry to QuadsNotTriples is marked by a GRAPH
which is never in triples.
The grammar is LL(1) - a lookahead of 1 - by default.
There are two solutions (I haven't checked exact deatils):
1/ Use LOOKAHEAD(2) so it sees tokens ':z' and ':q' or ':z' (triples)
and '{' which is the named graphs case. I think this is in Quads
somewhere.
2/ Leave GRAPH required.
(2) is fine for now - it will not be too unexpected to users because
INSERT DATA requires a GRAPH and it is legal TriG, even if not the short
form in TriG.
You can come back and look at (1) later. I'm keen for you to get
something going as soon as possible, not get lost in details.
Background:
There is a third solution but it's not as so simple which is to
introduce an intermediate state of MaybeTriplesMaybeQuads but if you
do that, more of the grammar needs rewriting. I'm not sure how
widespread the changes would be.
Jena's TriG parser (which is not JavaCC based see
LangTriG::oneNamedGraphBlock2)
has this comment:
// Either :s :p :o or :g { ... }
and does one look ahead to get the :s or :g (the :z above), keeps that
hanging around, does another lookahead to see '{' or not, then calls
turtle(n) if triples.
In LangTriG:
turtle() is roughly TriplesSameSubject
turtle(n) is roughly PropertyListNotEmpty
Andy
On 15/06/15 11:53, Qihong Lin wrote:
Hi,
I'm trying to play with master.jj. But the grammar script somethings
prints warning messages. The behavior is strange. In order to simplify
my question, I'd like to take the following example:
In QuadsNotTriples(), line 691 in master.jj, in the master branch:
GRAPH
If I change it to optional (which is required in future
implementations, for the new grammar):
(GRAPH)?
the grammar script goes like this:
$ ./grammar
Process grammar -- sparql_11.jj
Java Compiler Compiler Version 5.0 (Parser Generator)
(type javacc with no arguments for help)
Reading from file sparql_11.jj . . .
Warning: Choice conflict in [...] construct at line 464, column 4.
Expansion nested within construct and expansion following construct
have common prefixes, one of which is: VAR1
Consider using a lookahead of 2 or more for nested expansion.
Warning: Choice conflict in [...] construct at line 468, column 6.
Expansion nested within construct and expansion following construct
have common prefixes, one of which is: VAR1
Consider using a lookahead of 2 or more for nested expansion.
Warning: Choice conflict in [...] construct at line 484, column 12.
Expansion nested within construct and expansion following construct
have common prefixes, one of which is: VAR1
Consider using a lookahead of 2 or more for nested expansion.
Warning: Choice conflict in [...] construct at line 759, column 3.
Expansion nested within construct and expansion following construct
have common prefixes, one of which is: VAR1
Consider using a lookahead of 2 or more for nested expansion.
Warning: Choice conflict in [...] construct at line 767, column 5.
Expansion nested within construct and expansion following construct
have common prefixes, one of which is: VAR1
Consider using a lookahead of 2 or more for nested expansion.
File TokenMgrError.java does not exist. Will create one.
File ParseException.java does not exist. Will create one.
File Token.java does not exist. Will create one.
File JavaCharStream.java does not exist. Will create one.
Parser generated with 0 errors and 5 warnings.
Create text form
Java Compiler Compiler Version 5.0 (Documentation Generator Version 0.1.4)
(type jjdoc with no arguments for help)
Reading from file sparql_11.jj . . .
Grammar documentation generated successfully in sparql_11.txt
Fixing Java warnings in TokenManager ...
Fixing Java warnings in Token ...
Fixing Java warnings in TokenMgrError ...
Fixing Java warnings in SPARQLParser11 ...
Done
Process grammar -- arq.jj
Java Compiler Compiler Version 5.0 (Parser Generator)
(type javacc with no arguments for help)
Reading from file arq.jj . . .
Warning: Choice conflict in [...] construct at line 486, column 4.
Expansion nested within
Re: [GSoC 2015 - JENA-491] JavaCC with master.jj
Hi Qihong,
In addition to Andy's explanation, You might take look at this
tutorial for more details on javacc lookahead:
https://javacc.java.net/doc/lookahead.html
Best regards,
Ying Jiang
On Mon, Jun 15, 2015 at 10:42 PM, Andy Seaborne a...@apache.org wrote:
Qihong,
There is an ambiguity in the grammar if you make GRAPH optional.
See rule 'Quads'
Consider these two cases:
:s :p :o .
:z { :s1 :p1 :o1 } .
:s :p :o .
:z :q :o2 .
when the parser get to end of the triple in the default graph:
:s :p :o .
there are two ways forward: more triples (TriplesTemplate) and end of the
triples part, start of named graph.
It looks ahead one token and see :z and needs to decide whether the next
rule is more triples, the :z :q :o2 . case, or the end of the triples for
the default graph and the start of a named graph the :z { :s1 :p1 :o1 } .
where it exists TriplesTemplate and moves on to QuadsNotTriples
If GRAPH then the entry to QuadsNotTriples is marked by a GRAPH which is
never in triples.
The grammar is LL(1) - a lookahead of 1 - by default.
There are two solutions (I haven't checked exact deatils):
1/ Use LOOKAHEAD(2) so it sees tokens ':z' and ':q' or ':z' (triples) and
'{' which is the named graphs case. I think this is in Quads somewhere.
2/ Leave GRAPH required.
(2) is fine for now - it will not be too unexpected to users because INSERT
DATA requires a GRAPH and it is legal TriG, even if not the short form in
TriG.
You can come back and look at (1) later. I'm keen for you to get something
going as soon as possible, not get lost in details.
Background:
There is a third solution but it's not as so simple which is to introduce an
intermediate state of MaybeTriplesMaybeQuads but if you do that, more of
the grammar needs rewriting. I'm not sure how widespread the changes would
be.
Jena's TriG parser (which is not JavaCC based see
LangTriG::oneNamedGraphBlock2)
has this comment:
// Either :s :p :o or :g { ... }
and does one look ahead to get the :s or :g (the :z above), keeps that
hanging around, does another lookahead to see '{' or not, then calls
turtle(n) if triples.
In LangTriG:
turtle() is roughly TriplesSameSubject
turtle(n) is roughly PropertyListNotEmpty
Andy
On 15/06/15 11:53, Qihong Lin wrote:
Hi,
I'm trying to play with master.jj. But the grammar script somethings
prints warning messages. The behavior is strange. In order to simplify
my question, I'd like to take the following example:
In QuadsNotTriples(), line 691 in master.jj, in the master branch:
GRAPH
If I change it to optional (which is required in future
implementations, for the new grammar):
(GRAPH)?
the grammar script goes like this:
$ ./grammar
Process grammar -- sparql_11.jj
Java Compiler Compiler Version 5.0 (Parser Generator)
(type javacc with no arguments for help)
Reading from file sparql_11.jj . . .
Warning: Choice conflict in [...] construct at line 464, column 4.
Expansion nested within construct and expansion following
construct
have common prefixes, one of which is: VAR1
Consider using a lookahead of 2 or more for nested expansion.
Warning: Choice conflict in [...] construct at line 468, column 6.
Expansion nested within construct and expansion following
construct
have common prefixes, one of which is: VAR1
Consider using a lookahead of 2 or more for nested expansion.
Warning: Choice conflict in [...] construct at line 484, column 12.
Expansion nested within construct and expansion following
construct
have common prefixes, one of which is: VAR1
Consider using a lookahead of 2 or more for nested expansion.
Warning: Choice conflict in [...] construct at line 759, column 3.
Expansion nested within construct and expansion following
construct
have common prefixes, one of which is: VAR1
Consider using a lookahead of 2 or more for nested expansion.
Warning: Choice conflict in [...] construct at line 767, column 5.
Expansion nested within construct and expansion following
construct
have common prefixes, one of which is: VAR1
Consider using a lookahead of 2 or more for nested expansion.
File TokenMgrError.java does not exist. Will create one.
File ParseException.java does not exist. Will create one.
File Token.java does not exist. Will create one.
File JavaCharStream.java does not exist. Will create one.
Parser generated with 0 errors and 5 warnings.
Create text form
Java Compiler Compiler Version 5.0 (Documentation Generator Version 0.1.4)
(type jjdoc with no arguments for help)
Reading from file sparql_11.jj . . .
Grammar documentation generated successfully in sparql_11.txt
Fixing Java warnings in TokenManager ...
Fixing Java warnings in Token ...
Fixing Java
Definition of SPARQL variable pre-binding
Hi, (this question is motivated by the ongoing Data Shapes WG, but I don't speak on their behalf). Jena and other APIs such as Sesame support the concept of pre-binding variables prior to SPARQL execution, using QueryExecution.setInitialBinding(). This is convenient to reuse parameterized queries, especially with blank nodes. Question: is there any formal basis of this functionality, formulated so that it can be implemented by other platforms too? I can see that it populates the original bindings that are passed through the algebra objects, but what would be the best way to explain this by means of concepts from the SPARQL 1.1 spec? Thanks Holger
[jira] [Updated] (JENA-963) OpAsQuery does not process HAVING (COUNT(?value) 1) correctly.
[ https://issues.apache.org/jira/browse/JENA-963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Seaborne updated JENA-963: --- Attachment: ReportOpAsQuery.java OpAsQuery does not process HAVING (COUNT(?value) 1) correctly. Key: JENA-963 URL: https://issues.apache.org/jira/browse/JENA-963 Project: Apache Jena Issue Type: Bug Components: ARQ Affects Versions: Jena 3.0.0 Reporter: Andy Seaborne Attachments: ReportOpAsQuery.java Reported: http://mail-archives.apache.org/mod_mbox/jena-users/201506.mbox/%3CCA%2BEd63nzgDA_bShyhQvukED%2BPTiPxSAggo2VmD30J8ZwHr6vUA%40mail.gmail.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (JENA-963) OpAsQuery does not process HAVING (COUNT(?value) 1) correctly.
Andy Seaborne created JENA-963: -- Summary: OpAsQuery does not process HAVING (COUNT(?value) 1) correctly. Key: JENA-963 URL: https://issues.apache.org/jira/browse/JENA-963 Project: Apache Jena Issue Type: Bug Components: ARQ Affects Versions: Jena 3.0.0 Reporter: Andy Seaborne Reported: http://mail-archives.apache.org/mod_mbox/jena-users/201506.mbox/%3CCA%2BEd63nzgDA_bShyhQvukED%2BPTiPxSAggo2VmD30J8ZwHr6vUA%40mail.gmail.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
