Utiliser JNI au lieu de JNA pour appeler du code natif ?

Question

JNA semble un peu plus facile à utiliser pour appeler du code natif que JNI. Dans quels cas utiliseriez-vous JNI plutôt que JNA ?

Answer 1

1. JNA ne prend pas en charge le mappage des classes c++, donc si vous utilisez la bibliothèque c++, vous aurez besoin d'un wrapper JNA.
2. Si vous avez besoin de beaucoup de copies de mémoire. Par exemple, vous appelez une méthode qui vous renvoie un grand tampon d'octets, vous modifiez quelque chose dans celui-ci, puis vous devez appeler une autre méthode qui utilise ce tampon d'octets. Cela vous obligerait à copier ce tampon de c à java, puis à le recopier de java à c. Dans ce cas, jni gagnera en performance car vous pouvez conserver et modifier ce tampon en c, sans le copier.

Voici les problèmes que j'ai rencontrés. Il y en a peut-être d'autres. Mais en général, les performances ne sont pas si différentes entre jna et jni, donc si vous pouvez utiliser JNA, utilisez-le.

EDIT

Cette réponse semble être assez populaire. Voici donc quelques ajouts :

1. Si vous avez besoin de mapper C++ ou COM, il existe une bibliothèque d'Oliver Chafic, créateur de JNAerator, appelée BridJ . Il s'agit d'une bibliothèque encore jeune, mais elle présente de nombreuses caractéristiques intéressantes :
   • Interopérabilité dynamique C / C++ / COM : appelez des méthodes C++, créez des objets C++ (et sous-classez des classes C++ depuis Java !).
   • Correspondances de types simples avec une bonne utilisation des génériques (y compris un modèle beaucoup plus agréable pour les pointeurs).
   • Support complet de JNAerator
   • fonctionne sur Windows, Linux, MacOS X, Solaris, Android
2. En ce qui concerne la copie de mémoire, je crois que JNA supporte les ByteBuffers directs, ce qui permet d'éviter la copie de mémoire.

Ainsi, je continue de penser que, dans la mesure du possible, il est préférable d'utiliser JNA ou BridJ, et de revenir à jni si les performances sont critiques, car si vous devez appeler fréquemment des fonctions natives, la baisse des performances est sensible.

Answer 2

Il est difficile de répondre à une question aussi générique. Je suppose que la différence la plus évidente est qu'avec JNI, la conversion de type est implémentée du côté natif de la frontière Java/natif, alors qu'avec JNA, la conversion de type est implémentée en Java. Si vous êtes déjà à l'aise avec la programmation en C et que vous devez implémenter vous-même du code natif, je suppose que JNI ne vous semblera pas trop complexe. Si vous êtes un programmeur Java et que vous avez seulement besoin d'invoquer une bibliothèque native tierce, l'utilisation de JNA est probablement la voie la plus facile pour éviter les problèmes peut-être pas si évidents de JNI.

Bien que je n'aie jamais évalué les différences, je suppose, du fait de la conception, que la conversion de type avec JNA sera, dans certaines situations, moins performante qu'avec JNI. Par exemple, lors du passage de tableaux, JNA les convertira de Java en natif au début de chaque appel de fonction et inversement à la fin de l'appel de fonction. Avec JNI, vous pouvez contrôler vous-même le moment où une "vue" native du tableau est générée, en ne créant potentiellement qu'une vue d'une partie du tableau, en conservant la vue sur plusieurs appels de fonction et, à la fin, en libérant la vue et en décidant si vous voulez conserver les changements (ce qui peut nécessiter de recopier les données) ou rejeter les changements (aucune copie nécessaire). Je sais que vous pouvez utiliser un tableau natif à travers des appels de fonction avec JNA en utilisant la classe Memory, mais cela nécessitera également une copie de la mémoire, ce qui peut être inutile avec JNI. La différence peut ne pas être pertinente, mais si votre objectif initial est d'augmenter les performances de l'application en implémentant des parties de celle-ci en code natif, l'utilisation d'une technologie de pont moins performante ne semble pas être le choix le plus évident.

Answer 3

1. Vous écrivez du code il y a quelques années, avant l'existence de JNA, ou vous ciblez un JRE antérieur à la version 1.4.
2. Le code avec lequel vous travaillez n'est pas dans une DLL. \SO.
3. Vous travaillez sur du code qui est incompatible avec la LGPL.

C'est seulement ce que je peux trouver dans ma tête, bien que je ne sois pas un grand utilisateur de l'un ou l'autre. Il semble également que vous pourriez éviter JNA si vous vouliez une meilleure interface que celle qu'ils fournissent, mais vous pourriez coder autour de cela en Java.

Answer 4

À propos, dans l'un de nos projets, nous avons gardé une très petite empreinte JNI. Nous utilisions des tampons de protocole pour représenter nos objets de domaine et n'avions donc qu'une seule fonction native pour faire le lien entre Java et C (bien entendu, cette fonction C appelait ensuite un tas d'autres fonctions).

Answer 5

Ce n'est pas une réponse directe et je n'ai pas d'expérience avec la JNA mais, quand je regarde le Projets utilisant JNA et voir des noms comme SVNKit, IntelliJ IDEA, NetBeans IDE, etc., j'ai tendance à croire qu'il s'agit d'une bibliothèque plutôt décente.

En fait, je pense vraiment que j'aurais utilisé JNA au lieu de JNI quand j'ai dû le faire, car il semble effectivement plus simple que JNI (dont le processus de développement est ennuyeux). Dommage que JNA n'ait pas été publié à cette époque.