3.18-2016c appears to make testing difficult (Android)

[pickscrape]

I'm not entirely sure what the reasons are behind this, but I've not been able to get Android tests involving time4j working with 3.18-2016c. The test spinners just sit there: my guess is it's getting confused by the initialization taking place on a different thread?

Flipping the second parameter of ApplicationStarter.initialize to false causes tests that reference time4j classes to fail with stack traces beginning:

java.lang.ExceptionInInitializerError
    at net.time4j.android.spi.AndroidResourceLoader$LazyExtensions.iterator(Unknown Source)
    at net.time4j.PlainDate.registerExtensions(Unknown Source)
    at net.time4j.PlainDate.<clinit>(Unknown Source)

Downgrading to 3.17-2016b fixes the problem completely.

[MenoData]

Thanks for the message. I am going to investigate it within the next week. Do you say that setting the prefetch-parameter in the initialization-method to "true" is okay, but with value "false" fails?

[pickscrape]

With the value set to true, the tests don't run at all: they just seem to hang with their corresponding spinners spinning away. I did try pausing execution, and it looked like it was cycling between three different lines in the time4j library. Looked like it was maybe waiting for initialization, but I unfortunately didn't make notes of the lines in question.

With the value set to false, the tests fail quickly as described.

[MenoData]

Have got it so far. The problem with setting the prefetch-parameter to "true" was a deadlock-situation. The commits done now have solved the problem on my local system in emulator test.

About the other problem with ExceptionInInitializerError when setting the prefetch-parameter to "false", maybe you can show me how you refer to Time4A in your first two or three test classes because it is still not reproducible for me (I have a vague suspicion but it is also possible that that second problem has gone away with the commits done).

Really sorry for inconveniences but I think the next release solving the problems is not far away.

[pickscrape]

Thanks for the quick response! no rush on my part though: the previous working is working fine for my use case.

I'm testing via robolectric, so the actual ApplicationStarter.initialize(this, false); line in my application class is where the initialization takes place. In that case, a fuller stack trace looks like this:

    at net.time4j.android.spi.AndroidResourceLoader$LazyExtensions.iterator(Unknown Source)
    at net.time4j.PlainDate.registerExtensions(Unknown Source)
    at net.time4j.PlainDate.<clinit>(Unknown Source)
    at my.package.MyTest.testMyStuff(MyTest.java:53)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:483)
    at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
    at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
    at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
    at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
    at org.robolectric.RobolectricTestRunner$HelperTestRunner$1.evaluate(RobolectricTestRunner.java:564)
    at org.robolectric.RobolectricTestRunner$2.evaluate(RobolectricTestRunner.java:263)
    at org.robolectric.RobolectricTestRunner.runChild(RobolectricTestRunner.java:193)
    at org.robolectric.RobolectricTestRunner.runChild(RobolectricTestRunner.java:56)
    at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
    at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
    at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
    at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
    at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
    at org.robolectric.RobolectricTestRunner$1.evaluate(RobolectricTestRunner.java:159)
    at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
    at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
    at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:69)
    at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:234)
    at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:74)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:483)
    at com.intellij.rt.execution.application.AppMain.main(AppMain.java:144)
Caused by: java.lang.NullPointerException
    at net.time4j.tz.spi.TimezoneRepositoryProviderSPI.<init>(Unknown Source)
    at net.time4j.android.spi.AndroidResourceLoader$Iterables.<clinit>(Unknown Source)
    ... 32 more

That particular line in my test case is:

PlainDate origin = PlainDate.of(2014, 05, 03);

Though as you say, it's possible that your other fixes have already fixed this issue.

Thanks again!

[MenoData]

I have just now released Tim4A v3.19-2016c. Originally I wanted to wait until TZDB-version 2016d, but that is still not available. Please be so kind to give a short feedback if your problem is solved with newest version (I think so).

[MenoData]

Meanwhile even Time4A-v3.19-2016d has been released. I have myself not observed any problems. The stacktrace you sent was very informative, and especially the last commit referencing this issue addresses the problem described by the stacktrace.

[pickscrape]

Following up that I can confirm this fixed also. Thanks!

[MenoData]

Nice to hear your feedback. I appreciate it very much.