[
https://issues.apache.org/jira/browse/JENA-1294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexis Armin Huf updated JENA-1294:
-----------------------------------
Attachment: testInitFromRDFS.patch
[~andy.seaborne], I'm a newbie on jena internals, but I agree with your
proposal. As for the alternative I cannot see a reliable and simple way to
implement it.
I did a simple benchmark to get a feel of the overhead on using lazy static
methods that check the final fields for nulity:
{code:java}
List<Resource> dummy = new ArrayList<>(blockSize*runs);
for (int i = 0; i < runs; i++) {
Stopwatch watch = Stopwatch.createStarted();
for (int j = 0; j < blockSize; j++)
dummy.add(compute());
computeSum += watch.elapsed(TimeUnit.MICROSECONDS);
watch.reset().start();
for (int j = 0; j < blockSize; j++)
dummy.add(lazyField());
lazySum += watch.elapsed(TimeUnit.MICROSECONDS);
watch.reset().start();
for (int j = 0; j < blockSize; j++)
dummy.add(field);
fieldSum += watch.elapsed(TimeUnit.MICROSECONDS);
}
{code}
Averages are in microseconds per call (not block). Preheat runs are discarded
due to JVM JIT compiler.
{noformat}
preheat runs: 2 runs: 100, blockSize: 32
Avgs (us) compute: 1.208 lazyField: 0.163 field: 0.093
{noformat}
I'm not sure if this overhead would cause problems for some applications. It
looks fine for mine. Replacing all uses of vocabularies inside jena code with
method calls is probably a more robust solution.
As for testing it, spawning a JVM could do it. Is there a policy against JVM
spawning in Jena tests? I've attached a patch with a method in
{{TestSystemSetup}} do test this. If the test is included, then it would be
manageable to search all vocabulary use from jena initialization and replace
only those. As code changes, the test would fail.
Once devs agree on what to do, I can volunteer for the manual labour.
> 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)
