La Proposition d'Amélioration du JDK (JEP) 191 définit les Foreign Function Interface (FFI) en Java comme des interfaces qui peuvent connecter des fonctions natives à des méthodes Java et qui peuvent gérer des blocs de mémoire native. Cette JEP rendra plus aisé l'ajout de nouvelles fonctionnalités au JDK et aidera à fournir un FFI standard pour le développement Java. Java Native Interface (JNI) est le standard existant d'interface de programmation pour l'écriture de code Java natif. JNI n'est pas une manière simple de créer des fonctions natives, et cet état de fait a donné naissance à des librairies comme Java Native Access (JNA) et Java Native Runtime (JNR). JNA et JNR s'appuyent toutes deux sur JNI, et la JEP 191 sera vraisemblablement basée sur JNR.
Cette JEP fournit une Interface de Fonction Externe au niveau Java, de la même manière que JNA ou JNR. Elle permettra un accès simple aux fonctions natives, et gèrera la mémoire au niveau de la JVM. Elle supportera également une JSR future pour une FFI standard Java. L'API Java FFI peut être employée pour implémenter des fonctionnalités natives comme NIO, des meta-données avancées sur le système de fichier, et la gestion de processus. L'utilisation de l'API FFI sera la manière principale pour connecter le code et la mémoire natifs, au lieu de JNI. La JEP 191 ne comprend pas les améliorations de JNI, bien qu'elles puissent rejoindre le processus JSR.
JNI est l'actuel standard de programmation d'interface pour écrire des méthodes Java natives et pour embarquer la machine virtuelle Java dans des applications natives. Elle gouverne la frontière entre la JVM et l'environnement natif non-géré, et fournit les protocoles pour l'isolation des données et la gestion du cycle de vie des objets. D'après la JEP 191, voici les aspects de JNI les plus gênants pour les développeurs :
- L'obligation pour les développeurs d'écrire du code C implique qu'ils doivent avoir une expertise d'un monde complètement différent de Java ;
- L'utilisation de JNI nécessite une expertise qui n'existe généralement pas chez les développeurs Java et C typiques, car le dévelopeur doit posséder au moins une connaissance basique de la gestion de la mémoire et du code par la JVM ;
- Les développeurs doivent pouvoir créer le code pour chaque plate-forme qu'ils veulent supporter, ou doivent pouvoir fournir un outillage approprié pour que les utilisateurs finaux puissent le faire ;
- La performance des librairies basées sur JNI est en général faible en comparaison des mêmes librairies connectées à une application native ;
- JNI fait office de frontière opaque en termes de sécurité. Le JDK ne connaît pas les appels que les fonctions dans cette librairie pourraient faire, ni si le code dans la librairie pourrait compromettre la stabilité ou la sécurité de la JVM.
Les obstacles que pose JNI peuvent être adressés par une API FFI dans le et pour le JDK. Cette FFI Java serait facile à implémenter, et ne nécessiterait pas autant d'expertise dans les mécanismes internes de la JVM et des diverses plate-formes hôtes. L'API FFI fournira :
- Un système de méta-données pour décrire les appels des librairies natives et la structure de la mémoire native ;
- Des mécanismes pour découvrir et charger des librairies natives ;
- Des mécanismes pour connecter - en se basant sur des méta-données, une fonction/librairie ou une structure mémoire à un point d'entrée Java ;
- Du code pour transformer les types de données Java et types natifs et vice-versa.
La JEP 1919 peut également apporter l'optimisation JIT des appels natifs, une connaissance de la mémoire native au niveau du GC, ainsi que des mécanismes pour passer outre les garde-fous de JNI qui se révèlent inutiles. Elle incluera également des outils pour rassembler des méta-données sur les fonctions et la mémoire des librairies natives, basés sur la librairie ffi-gen de JRuby. Des stratégies de sécurité peuvent également être mises en place pour se connecter à des fonctions spécifiques, plutôt que des permissions au niveau de la librairie.
Le besoin de FFI Java a donné naissance aux librairies JNA et JNR. La bibliothèque JNA est plus largement utilisée. La bibliothèque JNR est plus puissante, car elle implémente plusieurs niveaux d'abstraction, elle fournit des méta-données sur les fonctions et la mémoire et elle enveloppe sous une couche d'abstraction la connexion aux librairies et aux fonctions. JNR a été fortement utilisée par le projet JRuby et servira certainement de socle à la JEP 191.