[
https://issues.apache.org/jira/browse/JENA-1294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15884197#comment-15884197
]
Andy Seaborne commented on JENA-1294:
-------------------------------------
I've just made a pull request with RDFS. RDF and OWL (the only other two
vocabularies affected) still to do in the same style of RDFS.Init.
The statics remain final. This means there fields are as before - the fields
are set during class initialization and can't be reset latest.
I doubt that performance would make an observable difference. It seems quite
unlikely they would be used in some tight loop that was big enough to be
noticeable. In the PR, they are are still final and still set by calculation.
What has changed is that the initialization code elsewhere calls the
calculation, not use the constant.
I like the patch with the init test - I'll add it to the PR. Spawning JVM
might a problem in some environments, we'll just have to see, but even it is
adding the test and ignoring at least collects the knowledge.
> JenaSystem.init from RDFS throws NPE, fails ARQ tests
> -----------------------------------------------------
>
> Key: JENA-1294
> URL: https://issues.apache.org/jira/browse/JENA-1294
> Project: Apache Jena
> Issue Type: Bug
> Components: ARQ, Core
> Affects Versions: Jena 3.2.0
> Environment: OpenJDK 1.8.0_121-b13
> Linux 4.9.8-1-ARCH #1 SMP PREEMPT x86_64 GNU/Linux
> Reporter: Alexis Armin Huf
> Assignee: Andy Seaborne
> Priority: Critical
> Attachments: call-init.patch, jena-rdfs-init.tar.gz,
> mvn-verify-arq-bug.log.gz, no-rdfs-on-init.patch, testInitFromRDFS.patch
>
>
> As discussed in #JENA-1290, jena-arq tests failed but committers could not
> reproduce the issue. The cause was that for some reason the first test that
> ran on was {{TestParameterizedSparqlString.test_param_string_injection_01}},
> and as the following stack trace shows, it reached {{JenaSystem.init}} from
> RDFS class initialization.
> At least 3 locations involved in core and ARQ initalization refer to
> {{RDFS.subClassOf}} and {{RDFS.member}} which are null and cannot be
> initialized because RDFS is already being initialized:
> {noformat}
> Init: JenaInitLevel0
> Init: InitJenaCore
> JenaCore.init - start
> RDF: http://www.w3.org/1999/02/22-rdf-syntax-ns#
> RDFS: http://www.w3.org/2000/01/rdf-schema#
> RDFS.subClassOf: null
> OWL: http://www.w3.org/2002/07/owl#
> JenaCore.init - finish
> Init: InitRIOT
> RIOT.init - start
> RIOT.init - finish
> Init: InitARQ
> ARQ.init - start
> ARQ.init - start.1
> ARQ.init - start.2
> ARQ.init - start.3
> ARQ.init - start.4
> AssemblerUtils.init - start
> AssemblerUtils.init.registerDataset - start
> implementWith(http://jena.hpl.hp.com/2005/11/Assembler#DefaultModel)
> RDFS.subClassOf==null: true
> nulls: 5876a9af 7993aa96 null e1204e1f
> java.lang.NullPointerException
> at org.apache.jena.rdf.model.impl.ModelCom.add(ModelCom.java:1192)
> at
> org.apache.jena.assembler.assemblers.AssemblerGroup$ExpandingAssemblerGroup.implementWith(AssemblerGroup.java:95)
> at
> org.apache.jena.assembler.ConstAssembler.general(ConstAssembler.java:137)
> at
> org.apache.jena.sparql.core.assembler.AssemblerUtils.registerDataset(AssemblerUtils.java:72)
> at
> org.apache.jena.sparql.core.assembler.AssemblerUtils.init(AssemblerUtils.java:61)
> at org.apache.jena.query.ARQ.init(ARQ.java:596)
> at org.apache.jena.sparql.system.InitARQ.start(InitARQ.java:29)
> at org.apache.jena.system.JenaSystem.lambda$init$2(JenaSystem.java:119)
> at java.util.ArrayList.forEach(ArrayList.java:1249)
> at org.apache.jena.system.JenaSystem.forEach(JenaSystem.java:194)
> at org.apache.jena.system.JenaSystem.forEach(JenaSystem.java:171)
> at org.apache.jena.system.JenaSystem.init(JenaSystem.java:117)
> at org.apache.jena.graph.NodeFactory.<clinit>(NodeFactory.java:32)
> at
> org.apache.jena.rdf.model.impl.ResourceImpl.fresh(ResourceImpl.java:135)
> at
> org.apache.jena.rdf.model.impl.ResourceImpl.<init>(ResourceImpl.java:85)
> at
> org.apache.jena.rdf.model.ResourceFactory$Impl.createResource(ResourceFactory.java:297)
> at
> org.apache.jena.rdf.model.ResourceFactory.createResource(ResourceFactory.java:92)
> at org.apache.jena.vocabulary.RDFS.resource(RDFS.java:36)
> at org.apache.jena.vocabulary.RDFS.<clinit>(RDFS.java:44)
> at org.apache.jena.shared.PrefixMapping.<clinit>(PrefixMapping.java:219)
> at
> org.apache.jena.query.TestParameterizedSparqlString.test_param_string_injection_01(TestParameterizedSparqlString.java:1382)
> {noformat}
> The same problem can be observed on a one-liner mwe (jena-rdfs-init):
> {noformat}
> public class App {
> public static void main(String[] args) {
> System.out.printf("subClassOf URI: %s\n", RDFS.subClassOf.toString());
> }
> }
> {noformat}
> The ARQ test issue can be fixed adding a call to {{JenaSystem.init}}
> (call-init.patch). However, if test order changes for someone, the problem
> re-appears.
> For Both the MWE and the test, replacing RDFS fields used in init code with
> {{RDF.getURI()+"localName"}} fixes it (no-rdfs-on-init.patch). It is a hack
> and the problem remains for if the MWE uses vocab classes (RDF and OWL) in
> place of RDFS.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
