On Mon, 16 Sep 2019 at 11:13, Jerven Bolleman <jerven.bolleman@sib.swiss>
wrote:

> Dear Jena devs,
>
> I sometimes have a strange exception depending on the order of JUnit
> tests being executed.
>

Tests can call JenaSystem.init() to explicitly cause initialization. It may
be a workaround for you.

Which version of the code is this?


>
> I was wondering if other users have seen the same.
>
> Mostly it seems a loop for static variables that kick of if other
> classes had not run ahead of time.
>
> In the DateTimeUtils there is still a bit of use of Gregorian.
> I was wondering if this can be reduced to use more of the java.util.time
> objects? would a patch to do so be welcome?
>

For 3.13.0 it switches to java.time
https://github.com/apache/jena/blob/master/jena-base/src/main/java/org/apache/jena/atlas/lib/DateTimeUtils.java
JENA-1756 - the behaviour of FastDateParser has changed.

The GregorianCalendar used is left as it's public methods and some old code
in Jena uses hands out Calendar.

I've (slowly) been looking at java.time for other use in ARQ -- its all
about details. java.time is ISO 8601 and not exactly XSD; e.g.
duration/period is different and the support for xsd:g* isn't there exactly.

    Andy






>
> Regards,
> Jerven
>
>
> java.lang.ExceptionInInitializerError
> at
>
> org.apache.jena.sparql.util.NodeFactoryExtra.nowAsDateTime(NodeFactoryExtra.java:232)
> at org.apache.jena.sparql.util.Context.setupContextExec(Context.java:365)
> at
>
> org.apache.jena.sparql.engine.QueryExecutionBase.<init>(QueryExecutionBase.java:107)
> at
>
> org.apache.jena.query.QueryExecutionFactory.make(QueryExecutionFactory.java:631)
> at
>
> org.apache.jena.query.QueryExecutionFactory.make(QueryExecutionFactory.java:614)
> at
>
> org.apache.jena.query.QueryExecutionFactory.make(QueryExecutionFactory.java:600)
> at
>
> org.apache.jena.query.QueryExecutionFactory.create(QueryExecutionFactory.java:146)
> at
>
> org.expasy.unirules.tools.BasicSparqlTest.testPureSparql(BasicSparqlTest.java:506)
> at
>
> org.expasy.unirules.tools.BasicSparqlTest.positionMatchingTest(BasicSparqlTest.java:485)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
>
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
>
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> Caused by: java.lang.NullPointerException
> at
>
> java.base/java.lang.String$CaseInsensitiveComparator.compare(String.java:1224)
> at
>
> java.base/java.lang.String$CaseInsensitiveComparator.compare(String.java:1218)
> at java.base/java.util.TreeMap.getEntryUsingComparator(TreeMap.java:374)
> at java.base/java.util.TreeMap.getEntry(TreeMap.java:343)
> at java.base/java.util.TreeMap.containsKey(TreeMap.java:231)
> at
>
> org.apache.commons.lang3.time.FastDateParser$TimeZoneStrategy.<init>(FastDateParser.java:784)
> at
>
> org.apache.commons.lang3.time.FastDateParser.getLocaleSpecificStrategy(FastDateParser.java:570)
> at
>
> org.apache.commons.lang3.time.FastDateParser.getStrategy(FastDateParser.java:539)
> at
> org.apache.commons.lang3.time.FastDateParser.init(FastDateParser.java:174)
> at
>
> org.apache.commons.lang3.time.FastDateParser.<init>(FastDateParser.java:145)
> at
>
> org.apache.commons.lang3.time.FastDateFormat.<init>(FastDateFormat.java:395)
> at
>
> org.apache.commons.lang3.time.FastDateFormat.<init>(FastDateFormat.java:379)
> at
>
> org.apache.commons.lang3.time.FastDateFormat$1.createInstance(FastDateFormat.java:101)
> at
>
> org.apache.commons.lang3.time.FastDateFormat$1.createInstance(FastDateFormat.java:98)
> at
> org.apache.commons.lang3.time.FormatCache.getInstance(FormatCache.java:82)
> at
>
> org.apache.commons.lang3.time.FastDateFormat.getInstance(FastDateFormat.java:129)
> at org.apache.jena.atlas.lib.DateTimeUtils.<clinit>(DateTimeUtils.java:34)
>

Reply via email to