Inconvénients de l'utilisation de l'interface native Java

Question

Je n'arrive pas à comprendre ces deux inconvénients de l'utilisation de JNI. Je voudrais en savoir plus à leur sujet :

• Difficile de déboguer une erreur d'exécution dans code natif

• Les erreurs dans le code JNI entraînent l'arrêt de toute la JVM et ne fournissent aucun mécanisme de reprise en douceur.

Answer 1

Difficile à déboguer

• Vous avez besoin d'un débogueur C / C++ pour déboguer le code natif. Il n'est pas possible de passer facilement du code Java au code C/C++. (bien qu'il soit possible de déboguer les deux simultanément. Je l'ai fait avec Eclipse et le plugin CDT, mais c'est pénible).

Erreurs dans JNI

• Un mauvais code C/C++ dans votre bibliothèque native peut provoquer / provoquera des vidages de noyau / des défauts de segmentation dont la JVM ne peut pas se remettre, de sorte que toute votre application se plante.

Answer 2

Vous perdrez l'un des avantages de l'utilisation de Java, votre application n'est plus indépendante de la plate-forme, et de nombreux autres problèmes en découlent : vous devrez peut-être supporter des DLL pour Windows et des fichiers .so pour Linux, chacun d'eux ayant son propre compilateur, des outils de débogage différents, des dépendances différentes et peut-être des bogues différents, une plus grande complexité pour votre processus de construction, plus de code à tester, etc.

Answer 3

Difficile de déboguer une erreur d'exécution dans un code natif

Avez-vous déjà vu une trace de pile en Java ? Ils sont très conviviaux et vous indiquent la plupart du temps le numéro de ligne, la méthode de la classe et ce qui a échoué. Vous n'avez pas cela dans le code natif.

Les erreurs dans le code JNI entraînent l'arrêt de toute la JVM et ne fournissent aucun mécanisme de reprise en douceur.

Lorsque vous exécutez du code Java, tout est exécuté sous le contrôle de la JVM. Si quelque chose ne va pas, la JVM peut s'en charger. Vous n'avez pas ce contrôle en utilisant du code natif.

Answer 4

Bien que cela ne devrait pas être le cas en théorie, en pratique, le code basé sur JNI s'est avéré très fragile - j'en ai fait un cauchemar de maintenance. De petits changements ou même simplement des mises à jour de la JVM causent des problèmes obscurs. La situation s'est peut-être améliorée avec les versions plus récentes de Java (je me réfère ici au JDK 1.3 ou plus ancien).

Answer 5

Je ne suis pas sûr pour JNI, mais si vous utilisez JNA vous pouvez définir Native.setProtected(true) et il lancera une erreur au lieu de planter la JVM, afin que vous puissiez l'attraper dans le bloc try...catch. Le deuxième inconvénient n'est donc pas un problème. (voir code source )