Calling a method on a class for the first time on a secondary thread fails.

[jwhpryor]

This seems to be an issue with caching not occurring properly, despite a ThreadGuard being held.

To workaround, call any method on a class from the main thread and all subsequent calls will work.

[jwhpryor]

I started looking at this and I've discovered that this is inconsistent behavior between Android and vanilla java. Curiously, I can write a test that only fails on Android but the identical test fails with vanilla Java.

Updates to follow (and if folks have seen this outside of Android I'm keen to know).

[jwhpryor]

I believe this relates to the problem:
https://groups.google.com/g/android-ndk/c/eYL9tYkvefs

In fact, there are a couple threads posted which seem to be this specific Android issue.

I have a couple ideas I can try. I think if I cache the loader during the OnLoad call, it hopefully will work. I need to make sure this wouldn't induce breaking changes elsewhere (and, I presume it would work, but the devil is in the details).

[jwhpryor]

Possibly also this:
https://stackoverflow.com/questions/13263340/findclass-from-any-thread-in-android-jni

[jwhpryor]

So, I've invested a non-zero amount of time trying to resolve this, and I think this cannot be resolved without breaking or confusing behaviour for end users .

The issue is that any JNI call is effectively bound to the loader of the class that initiated the call. For Android, this means the application class loader, but when new threads are spun up, they do not have the same classloader, and fail to find the user defined class.

The only workaround is to call loadClass ahead of time, but JNI Bind doesn't know what class names are going to be used, so it actually can't. I think I could go to complicated lengths to work around this (e.g. having some type of callback mechanism), but I think it would be pretty unexpected for an end user to have this happen (and could cause side effects).

I'll try add a syntax like so to workaround, but at the end of the day I think there's nothing I can do unfortunately.

JvmRef jvm_ref {vm};
jvm_ref.Warm<kClassUsedOnOtherThread>()

[jwhpryor]

So, I continued to plug away at this, and it turns out the mistake was partly a cacheing mistake. TL;DR: I managed to get a fallback class loader to work for classes that fail lookup.

The unfortunate part is that it requires some extra setup from the caller, however, it's fairly minor. Basically the caller just has to provide a single instance of the host activity so that it can cache the application cache loader (you won't have to spell out each class type which would be easy to forget).

[jwhpryor]

FYI I uploaded the Android test that I used to test this fix here.

Sadly, I haven't managed to get these tests running under Bazel, but it at least shows the correct flow.