FindClass à partir de n'importe quel thread dans Android JNI

Android JNI page conseils mentionne cette FAQ: Pourquoi ne pas FindClass à trouver ma classe?
Ils mentionnent plusieurs solutions et la dernière option est celle-ci:

Cache une référence pour le chargeur de classe de l'objet quelque part est pratique, et la question
loadClass appels directement. Cela nécessite un certain effort.

Donc, j'ai essayé de le faire fonctionner et il semble que peu importe, cette méthode ne fonctionne tout simplement pas pour moi. Finalement, j'ai compris comment utiliser le chargeur de classe, mais cela ne fonctionnera pas si à partir d'un thread natif j'essaie de loadClass qui n'a pas été touché/encore chargé. C'est essentiellement identique à l'env->FindClass de comportement lorsqu'il est appelé à partir d'un thread natif, à l'exception qu'il ne renvoie pas 0 pour les classes qui ont été déjà utilisés dans l'application. Aucune idée si je n'ai pas l'obtenir, ou il est impossible d'accéder aux classes à partir d'un thread natif qui n'étaient pas utilisés ou encore chargé.

EDIT: je vais vous donner plus d'informations pour expliquer exactement ce que je veux dire. Il est régulier de JNI env->FindClass(className), et un autre que j'ai écrit myFindClass(env, className) qui utilise la mise en cache ClassLoader->loadClass.

La classe que j'essaye d'accéder à de natif c/c++ est "com/noname/TestClient". À l'intérieur de myFindClass j'ai aussi utiliser env->FindClass et journal de la valeur qu'elle renvoie:

jclass myFindClass(JNIEnv * env, const char* name)
{
    ...
    jclass c0 = env->FindClass(name);
    jclass c1 = (jclass)env->CallObjectMethod(ClassLoader,
        MID_loadClass, envNewStringUTF(name));
    dlog("myFindClass(\"%s\") => c0:%p, c1:%p, c0 and c1 are same: %d",
        name, c0, c1, env->IsSameObject(c0, c1));
    ...
}

Ensuite, j'ai ces 3 combinaisons pour expliquer le problème.

//inside JNI_OnLoad thread
myFindClass(env, "com/noname/TestClient");
...

//inside native thread created by pthread_create
myFindClass(env, "com/noname/TestClient");

- Je obtenir ce logcat:

myFindClass("com/noname/TestClent") => c0:0x41b64558, c1:0x41b64558,
c0 et c1 sont les mêmes: 1
...
myFindClass("com/noname/TestClent") => c0:0,
c1:0x41b64558, c0 et c1 sont les mêmes: 0

//inside JNI_OnLoad thread
env->FindClass("com/noname/TestClient");
...

//inside native thread created by pthread_create
myFindClass("com/noname/TestClient");

- Je obtenir ce logcat:

myFindClass("com/noname/TestClent") => c0:0, c1:0x41b64558, c0 et c1 sont les mêmes: 0

//inside JNI_OnLoad thread
//"com/noname/TestClient" isn't touched from JNI_OnLoad.
...

//inside native thread created by pthread_create
myFindClass(env, "com/noname/TestClient");

- Je obtenir ce logcat:

myFindClass("com/noname/TestClent") => c0:0, c1:0, c0 et c1 sont les mêmes: 1

En gros, mon problème est que le chargeur de classe ne trouve pas de ma classe dans le 3ème cas. Est-ce un bug? Ce qui peut être fait pour résoudre le problème?

EDIT2:
En plus de cela, il semble que le chargeur de classe::loadClass est clairement buggy. Si je demande myFindClass("noname/TestClent") ensuite, il retourne à certaines des ordures, et quand j'utilise ce qui est retourné jclass en aucune façon l'application se bloque.

Oui, c'est normal, les applications Android ne pas utiliser le système de chargeur de classe par défaut. Juste cache tout que vous avez besoin dans JNI_OnLoad() et qui prendra soin de cela.
Re: EDIT2: on dirait que la méthode a déclenché une exception, à quel point la valeur de retour n'est pas défini. loadClass() jamais renvoie null; elle renvoie soit la classe de référence ou elle lève une exception.
elle pourrait l'être. Je ne me souviens pas exactement quel était le problème, mais je l'ai résolu par la suite.

InformationsquelleAutor Pavel | 2012-11-07

android c++java-native-interface

55

Après beaucoup d'essayer et de s'écraser de mon application, un collègue et j'ai réussi à le cache et réussi à utiliser le chargeur de classe dans une autre, natif, fil. Le code que nous avons utilisé est indiqué ci-dessous (C++11, mais peut facilement être converti en C++2003), posté ici car nous n'avons pas trouvé d'exemples de cette "Cache une référence pour le chargeur de classe de l'objet quelque part est pratique, et la question loadClass appels directement. Cela nécessite un certain effort.". L'appel de findClass a parfaitement fonctionné lorsqu'il est appelé à partir d'un thread différent de celui de JNI_OnLoad. J'espère que cette aide.
```
JavaVM* gJvm = nullptr;
static jobject gClassLoader;
static jmethodID gFindClassMethod;

JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM *pjvm, void *reserved) {
    gJvm = pjvm;  //cache the JavaVM pointer
    auto env = getEnv();
    //replace with one of your classes in the line below
    auto randomClass = env->FindClass("com/example/RandomClass");
    jclass classClass = env->GetObjectClass(randomClass);
    auto classLoaderClass = env->FindClass("java/lang/ClassLoader");
    auto getClassLoaderMethod = env->GetMethodID(classClass, "getClassLoader",
                                             "()Ljava/lang/ClassLoader;");
    gClassLoader = env->CallObjectMethod(randomClass, getClassLoaderMethod);
    gFindClassMethod = env->GetMethodID(classLoaderClass, "findClass",
                                    "(Ljava/lang/String;)Ljava/lang/Class;");

    return JNI_VERSION_1_6;
}

jclass findClass(const char* name) {
    return static_cast<jclass>(getEnv()->CallObjectMethod(gClassLoader, gFindClassMethod, getEnv()->NewStringUTF(name)));
}

JNIEnv* getEnv() {
    JNIEnv *env;
    int status = gJvm->GetEnv((void**)&env, JNI_VERSION_1_6);
    if(status < 0) {    
        status = gJvm->AttachCurrentThread(&env, NULL);
        if(status < 0) {        
            return nullptr;
        }
    }
    return env;
}
```
- ClassLoader.loadClass() ne retourne pas null si la classe n'est pas trouvé. Elle lève une exception, ce qui signifie que la valeur de retour n'est pas défini. Vous devez vérifier les exceptions après l'appel de CallObjectMethod, et vous ne devez pas utiliser la valeur de retour si une exception a été soulevée. (Ce qui est vrai en général-tout Call*Method invocation doit être suivie par ExceptionCheck ou ExceptionOccurred, et vous pouvez voir l'exception, dans le journal, avec ExceptionDescribe.)
- Vrai, nous n'avons pas essayer de l'attraper java exceptions, mais il fonctionne pour ce que nous faisions et autant que j'ai cherché je ne vois pas de ligne de code pour résoudre ce problème particulier. Elle peut et doit être étoffé mais j'ai posté au serveur comme un guide pour les autres personnes. Il peut être modifié dans le futur.
- Je comprends; je voulais juste assurez-vous que quelqu'un qui n'a copier ajouté les vérifications nécessaires pour JNI_OnLoad et findClass (surtout le dernier -- vous pouvez convertir une exception à NULL, et claire l'exception, pour obtenir la sémantique que vous voulez). Notez également que vous n'avez pas besoin d'appeler FindClass pour trouver java.lang.Class; vous pouvez simplement utiliser GetObjectClass sur le jclass que vous avez déjà (c'est plus rapide et ne manque jamais sur un objet valide). Avez-vous essayé sur Android >= 4.0? Ressemble vous avez besoin d'un NewGlobalRef sur gFindClassMethod.
- Ouais. J'ai couru sur une Galaxy Tab trop avec android 4.0.3.
- Cool. FWIW, je voulais dire gClassLoader -- gFindClassMethod est un jmethodID.
- Excelent réponse... Juste un commentaire, cela n'a pas fonctionné pour moi à cause de ça : stackoverflow.com/questions/14765776/.... Après l'appel de NewGlobalRef() sur le gClassLoader objet, cela a résolu mon problème. Merci!
- LarryPel, qui semblait être ma question, mais il me laisse un peu perplexe: pourquoi ne pouvez-vous pas juste charger la classe spécifique dont vous avez réellement besoin et ensuite de créer un NewGlobalRef() pour que, plutôt que de passer par cette longue procédure? Ou suis-je malentendu façon générale, cette solution est? Le fait qu'ils ont besoin d'instancier randomClass m'a fait penser qu'il était un grand nombre d'étapes pour charger randomClass dans le futur fils.
- Plutôt que de prendre le chargeur de classes à partir d'un hasard de classe, vous pouvez tout simplement obtenir à partir de ce Thread.currentThread().getContextClassLoader() dans JNI_OnLoad (via JNI bien sûr), puis de les mettre en cache pour une utilisation ultérieure.
- Merci! J'ai utilisé une version modifiée de cette approche pour résoudre un problème avec asynch rappels à venir à partir de Google Play Jeux c++ sdk rappels sur la non JVM threads qui ont été ensuite tenter de faire des appels via JNI à la Java côté de l'intérieur d'une cocos2d-x v2.2.5 projet. (j'espère que ces mots-clés dans ces commentaires vont aider quelqu'un à trouver la réponse plus rapide...)
- Pourquoi est - classClass nécessaire? Mon code pauses si je plutôt passer randomClass en GetMethodID, mais je ne sais pas pourquoi, puisqu'il devrait être la même chose, non? Est-ce parce que la classe en question est com/*? Comment avez-vous su pour ce faire, et il y a toutes les références ou les documents que vous pouvez m'indiquer? Merci!
- merci pour la solution. remarque vous devez appeler NewGlobalRef() AVANT ce est stocké dans le monde. l'appel de NewGlobalRef() à partir d'un autre thread n'est pas d'aller travailler. Faire comme tels: gClassLoader = env->NewGlobalRef(env->CallObjectMethod(myClass, getClassLoaderMethod)); Pour plus de détails voir ici: android-développeurs.blogspot.kr/2011/11/...
- Pete, j'espérais vraiment que le Thread appelant.currentThread().getContextClassLoader() dans JNI_OnLoad serait de travailler (car il ne nécessite pas de connaître le nom d'une classe dans le non-module de système, ce qui est laid), mais malheureusement il ne fonctionne pas. Que des chargeurs de classes n'est PAS celui qui sait à propos de mon non-système de classes et échoue lorsque plus tard, j'ai essayer de chargeur de classe.findClass (même si je le fais à partir de JNI_OnLoad lui-même). Eh bien, bonne idée. Pour vérifier, je l'ai fait dans les deux sens et a confirmé que env->IsSameObject est FAUX pour les deux chargeurs de classes.
- Aussi, pour les personnes qui mettent en œuvre le présent, sachez que le chargeur de classe vous extrait (celui qui sait à propos de vos classes) ne savent PAS à propos de certains Android classes comme android.app.De l'activité. Si vous avez vraiment pour essayer les deux en tout usage général findClass routine. SOUPIR---pouvaient-ils faire JNI plus difficile à utiliser?
- merci pour les conseils!
- est un moyen simple d'obtenir une référence à java.lang.Class, ce qui est nécessaire pour la getMethodID appel depuis getClassLoader est un membre de java.lang.Class.
- Est le chargeur de classe thread-safe? Ou peut-il y avoir une course-condition si deux threads appel findClass sur le même chargeur de classe de référence en même temps? Est-il une différence entre findClass et loadClass? La chaîne de caractères retournée par NewStringUtf doit probablement être supprimé avec DeleteLocalRef?
InformationsquelleAutor Átila Neves
6

Essayez de fixer votre thread natif de la JVM en premier.

Le pointeur de jvm vous pouvez obtenir la première chose JNI_OnLoad
```
env->GetJavaVM(&jvm);
```
Puis, à partir de votre thread natif
```
JNIEnv *env;
jvm->AttachCurrentThread((void **)&env, NULL);
```
Ensuite l'utiliser env pour FindClass
- Alex, bien entendu, j'ai fais que, sans elle, 1) et 2) ne fonctionne pas 🙂
InformationsquelleAutor Alexander Kulyakhtin

Vous devez vous connecter pour publier un commentaire.