java.lang.NoSuchMethodError on Toothpick.reset() on Instrumentation Tests

[kelsos]

Hi,

I had an issue while running a couple of instrumentation tests on Android with Toothpick 1.0.3.
The issue is the following and doesn't appear to happen with v1.0.2:

java.lang.NoSuchMethodError: No virtual method keySet()Ljava/util/concurrent/ConcurrentHashMap$KeySetView; in class Ljava/util/concurrent/ConcurrentH
ashMap; or its super classes (declaration of 'java.util.concurrent.ConcurrentHashMap' appears in /system/framework/core-libart.jar)
        at toothpick.Toothpick.reset(Toothpick.java:125)...

This always happens when the tear down method calls the Toothpick.reset() method.

[dlemures]

http://valery-frolov.blogspot.com.es/2015/04/javalangnosuchmethoderror.html

[efung]

@kelsos Are you compiling with sourceCompatibility JavaVersion.VERSION_1_8? We're using Retrolambda and ran into this also.

There's some discussion of this issue in https://code.google.com/p/android/issues/detail?id=215828 as well as in https://gist.github.com/AlainODea/1375759b8720a3f9f094

However, it sounds like in the Android API, the return type of keySet() is still Set<K>?

[kelsos]

@efung No the source code and tests are all in kotlin.

[efung]

Hmm. I don't get it: why is this happening then? Is it because the toothpick artifacts were compiled against Java 1.8? (But I see source compatibility of 1.7 in the project.)

[kelsos]

@efung when I was searching for the cause I found this discussion http://stackoverflow.com/questions/32954041/concurrenthashmap-crashing-application-compiled-with-jdk-8-but-targeting-jre-7

[stephanenicolas]

The problem is related to a different implementation in jdk 8 and Android SDK which is based on java 5/7.

We think we got a workaround

[efung]

Ah, so is the issue that you compiled the artifacts for Toothpick with JDK 1.8? I'm trying to make sense of this comment against the sourceCompatibility of 1.7 in Toothpick's build.gradle

[dlemures]

Yes, we are compiling with JDK 1.8.

PR with workaround: #190

[stephanenicolas]

Just to say that the PR is actually a fix, not a workaround. A workaround would be to use JDK 8... 2017-01-18 13:02 GMT-08:00 Daniel Molinero <notifications@github.com>:

…

Yes, we are compiling with JDK 1.8. PR with workaround: #190 <#190> — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#186 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABv33XYb9_YYkYYMtnjsJ1WXELJiuUyJks5rTn3RgaJpZM4LdOLa> .

[dlemures]

PR merged.

@kelsos Could you update the issue once 1.0.4 is released?

[kelsos]

@dlemures Yes I will update it after the release.

[dlemures]

@kelsos I released a snapshot with the changes: 1.0.4-SNAPSHOT

Can you try it?

[kelsos]

@dlemures I tried the snapshot and it seems to work fine. The error is gone.

[dlemures]

Awesome. Thx for the help!
Closing