UnsatisfiedLinkError sur methode

Bonjour à tous,

je cherche une solution à mon problème qui semble être courant mais sans succès.

J'obtiens le message d'erreur suivant :

Code:

---

1 2 3 4 5 6

java.lang.UnsatisfiedLinkError: maMethode at package.monInterface.maMethode(Native Method) at autre.package.methodeAppelantLaPrecedente(MaClasse.java:129) at autre.package.run(Moteur.java:387) at java.lang.Thread.run(Unknown Source)

---

Je fais un appel à la méthode System.loadLibrary ou System.load :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

public void chargerDLL() {   try { System.loadLibrary("maLibDLL"); } catch (java.lang.UnsatisfiedLinkError e) {   File file = new File("");   String os = System.getProperty("os.name"); if (os.startsWith("Win")) { try { System.load( file.getAbsolutePath() + "/lib/maLibDLL.dll"); } catch (java.lang.UnsatisfiedLinkError ule) { ... } } }

---

Visiblement il ne trouve pas la méthode native maMethode...
Quelqu'un aurait il connu le même problème ?

Merci beaucoup

Bonjour, ta dll doit être spécifiée dans le classpath ou située dans un répertoire qui lui est dans le classpath.

Salut, je travaille avec Eclipse. Je suis en train de poursuivre un projet qui avait été débuté mais inachevé. L'application se sert d'une autre dll mais je ne la vois pas apparaitre dans le classpath, et pourtant ça marche très bien.

Je ne suis pas sur de bien comprendre...

Ah, oui en effet, autant pour moi ! Tu as raison !
Merci beaucoup !

Pourtant il n'y a pas d'autres solutions, soit la dll est dans le path, soit on la charge en faisant System.load(path) et dans ce cas on utilises un chemin complet.
D'après ton code, si la dll n'est pas dans le path, ça va chercher dans le répertoire lib de ton application.

EDIT ok :)

En fait ça ne marche pas non plus. Ce qu'il se passe c'est que la dll est bien chargée au début mais après au lancement de la fonction ça plante.

L'application utilise des moteurs permettant de faire des opérations, selon un mode de fonctionnement on va charger une dll plutot qu'une autre.
Dans Eclipse je vois qu'il suffit d'ajouter le dossier lib contenant les dll. J'ai procédé de la même façon pour créer mon moteur mais ce ne fonctionne pas mieux.

Le classpath c'est bien là ou on ajoute les dépendances comme par exemple des jar ou autre ressources? Je ne vois pas de dossier incluant des dll pour l'ancien moteur...

Regarde où se trouve la dll de l'ancien moteur et tu mets la nouvelle au même endroit ;)
J'ai déja vu des gens mettre les dll dans windows/system32, qui se trouve par défaut dans le path de windows.

Oui j'ai mis les dll au bon endroit exactement comme le précédent moteur. Mias je m'interroge sur le fait de chargé la dll si c'est la bonne manière de faire.

Je possède une classe abstraite me permettant d'appeler les méthodes de la dll, dans mon application Java or dans cette classe j'ai viré le chargement de la dll (le static):

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

public abstract class monInterface extends Object {   static { try { //load ici } catch(UnsatisfiedLinkError ule) { //blabla } } /**          * Default constructor for class monInterface          */ public monInterface () {   } }

---

pour le mettre dans une methode de chargement ou je peux faire :

Code:

---

1 2	monAPI.chargerDLL();

---

Est ce que cela peut être à cause de ce changement et de la privation du static {...} dans la classe abstraite ?

A mon avis c'est mieu de le faire en static, au moins tu es sûr que ce ne sera pas oublié et que ce sera fais une seule fois.
A prioris il n'y a pas de raison que l'erreur vienne de ce changement, si la méthode chargerDLL est bien appelée.

L'exception à lieu au chargement de la dll ou à l'appel d'une méthode? est-ce que la méthode existe bien dans la dll?

Mais sauf ce problème de static d'ou ca peut provenir, vraiment je ne comprends pas du tout...La dll est bien chargée nickel et bizarrement il ne trouve pas les fonctions.....

Bon...je vais partir du boulot, merci de m'avoir aidé, en espérant trouver la solution demain.

Bonne journée.

Ok, c'est bon ! Après avoir passé toute la matinée sur mon problème, j'ai enfin la solution.
Ce n'était pas un mauvais chargement de la dll ou un problème avec le classpath d'eclipse mais un problème de déclaration de prototype.

Pour ceux qui rencontrent le même problème, voici une probable solution :

Le prototype dans les méthodes de la dll declare le package, par exemple :

Code:

---

1 2 3

JNIEXPORT jint JNICALL Java_mon_package_MaClasseInterfaceJava_maMethode (JNIEnv *, jclass,...);

---

la declaration "mon_package" doit être identique dans java ainsi que "MaClasseInterfaceJava".

Bonne journée !