Je ne peux pas obtenir ces deux inconvénients de l'utilisation de JNI. Je veux en savoir plus sur eux:
Erreur d'exécution difficile à déboguer dans Code natif
Erreurs dans le code JNI dépose toute la JVM et ne fournissez aucun mécanisme de récupération gracieuse
6 Réponses :
+1 pour CoreDump / Segfault Crashing the JVM. Nous avons eu un code de traitement de signal (JNI) fonctionnant comme une tâche d'indexation de fond dans notre instance Tomcat. Un léger faux pas dans Jni et Tomcat était Toast.
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 impliqués à partir de celui-ci: peut-être que vous soutiendrez des fichiers DLL pour Windows et .so pour Linux, chacun de ils avec leur propre compilateur, différents outils de débogage, différentes dépendances et peut-être des bugs différents, plus de complexité pour votre processus de construction, plus de code à tester, etc.
Pire encore: Support Windows (32,64), Linux (32,64, différentes distributions), Solaris8,9,10 (SPARC, SPARCV9, 32, 64) ... Essayer de rédiger un code natif de la plate-forme croix correcte pour tous ceux-ci. Bienvenue à Fakefile Hell.
Bien que cela ne soit pas le cas en théorie, dans la pratique, le code basé sur JNI que j'ai trouvé très fragile - j'ai trouvé que c'était un cauchemar de maintenance. Les petits changements ou même les mises à niveau JVM provoquent des problèmes obscur. Cela peut s'être amélioré avec des versions Java plus récentes (je retourne à JDK 1.3 ou plus tôt ici).
Je ne suis pas sûr de JNI, mais si vous utilisez JNA , vous peut définir natif.setprotéecté (true) et il lancera une erreur au lieu de casser la JVM, de sorte que vous puissiez l'attraper en tessant ... Un deuxième inconvénient n'est donc pas un problème. (Voir code source )
J'ai de sérieux doutes à ce sujet. Les bits aléatoires de Code C pourraient, en théorie, enlever la machine si vous gâchez-vous. À ce stade, peu importe que la JVM soit directement protégée contre la faute.
I La plupart des cas (généralement un accès à la mémoire non valide), JVM le trouvera et donnera une chance de récupérer. Je ne pense pas que vous ayez même cette fonctionnalité avec pure C. et si on écrit du code qui décollera la machine ... Java n'est pas celui à blâmer.
Je ne sais pas si cela aide, mais j'ai utilisé une méthode natale pour définir un drapeau statique dans mon code JNI / C pour activer ou désactiver le traçage de débogage (par défaut est éteint). Ensuite, j'ai utilisé de bons appels imaginaires () au début de chaque fonction JNI qui n'a exécuté que si le drapeau était défini. C'est brut mais ça marche.
C'est aussi une bonne idée de fournir une sorte de vérification de la version entre la classe Java et ses fonctions JNI. Cela peut être fait avec une fonction JNI qui est appelée à partir d'un bloc d'initialisateur de classe statique. Si le client a la mauvaise combinaison de bibliothèques (c'est-à-dire que le JARFILE a été mis à jour, mais la bibliothèque partagée JNI n'a pas fait, ni inversement), vous pouvez organiser une exception au moment de la classe de classe.
Erreur d'exécution difficile à déboguer dans le code natif
Avez-vous déjà vu une stacktrace en Java? Eh bien, ils sont très conviviaux et ils vous disent la plupart du temps, le numéro de ligne, la méthode de classe et ce qui a échoué. Vous n'avez pas ceux sur le code natif.
Erreurs dans le code JNI Tenlevez toute la JVM et ne fournissez aucun mécanisme de récupération gracieuse
Lorsque vous exécutez le code Java, tout est exécuté sous le contrôle de la JVM, si quelque chose ne va pas, le JVM peut le gérer. Vous n'avez pas ce contrôle à l'aide de code natif.
Oscar, code natif contient des fichiers principaux (sur * Nix au moins). Vous pouvez obtenir beaucoup plus d'informations d'un fichier principal qu'une stacktrace Java, si vous savez ce que vous faites. Bien qu'il faut plus d'efforts pour travailler avec des fichiers principaux
@Glen: "... il faut plus d'efforts pour travailler avec des fichiers principaux ..." D'où "difficile à déboguer une erreur d'exécution dans le code natif". Je n'ai pas eu l'intention de prétendre que cela n'était pas possible, mais de clarifier, pourquoi est-ce plus difficile.