Projet Panama : une future alternative à Java Native Interface fait son apparition
Pour offrir un interfaçage natif avec les API C et C++
Le 2014-06-19 10:43:31, par Arsene Newman, Expert éminent sénior
Peu nombreuses sont les alternatives à Java Native Interface (JNI). Mais, cette famille très sélecte risque de s’agrandir prochainement grâce au Projet Panama.
Initié par le consultant Oracle John Rose au mois de mars, le Projet Panama a pour but de développer une manière native d’interconnecter du code géré par la JVM avec des API externes, offrant par la même occasion une meilleure expérience utilisateur pour les développeurs Java qui sollicitent des API écrites en C et C++.
« Le principal avantage de cette proposition est qu’elle va ouvrir le monde des bibliothèques natives (écrites en C ou dans d’autres langages similaires) aux développeurs Java sans avoir à écrire un code spécifique, mais simplement du code Java » a déclaré Charles Nutter partisan du projet. De son côté, John Rose estime que « développer pareil outil permettra un interfaçage plus rapide et moins couteux entre les applications Java et les API natives, un peu comme le canal de Panama qui a été creusé dans la roche et qui permet de relier l’océan Atlantique à l’océan Pacifique ».
Trois mois après avoir initié le projet à travers une proposition sur la mailing list d’Open JDK, il semblerait que le projet commence à prendre forme. Rose a soumis une proposition officielle, alors que la communauté OpenJDK se mobilise pour offrir le meilleur support possible au projet.
Enfin, il est important de noter que la proposition officielle sera soumise à délibération et à un vote par les membres d’OpenJDK très prochainement. Elle contient les principales directives du projet qui se résume à :
Source : Billet de blog de John Rose, Annonce officielle
Et vous ?
Qu’en pensez-vous ?
Initié par le consultant Oracle John Rose au mois de mars, le Projet Panama a pour but de développer une manière native d’interconnecter du code géré par la JVM avec des API externes, offrant par la même occasion une meilleure expérience utilisateur pour les développeurs Java qui sollicitent des API écrites en C et C++.
« Le principal avantage de cette proposition est qu’elle va ouvrir le monde des bibliothèques natives (écrites en C ou dans d’autres langages similaires) aux développeurs Java sans avoir à écrire un code spécifique, mais simplement du code Java » a déclaré Charles Nutter partisan du projet. De son côté, John Rose estime que « développer pareil outil permettra un interfaçage plus rapide et moins couteux entre les applications Java et les API natives, un peu comme le canal de Panama qui a été creusé dans la roche et qui permet de relier l’océan Atlantique à l’océan Pacifique ».
Trois mois après avoir initié le projet à travers une proposition sur la mailing list d’Open JDK, il semblerait que le projet commence à prendre forme. Rose a soumis une proposition officielle, alors que la communauté OpenJDK se mobilise pour offrir le meilleur support possible au projet.
Enfin, il est important de noter que la proposition officielle sera soumise à délibération et à un vote par les membres d’OpenJDK très prochainement. Elle contient les principales directives du projet qui se résume à :
- un accès natif aux données et au code entre la JVM et les API natives ;
- le développement d’un outil pour l’extraction des en-têtes API et des métadonnées de stockage ;
- un mapping pour la transformation des valeurs et pour certains invariants ;
- une prise en charge des API natives présélectionnées.
Source : Billet de blog de John Rose, Annonce officielle
Et vous ?
-
tchize_Expert éminent séniorEt qu'est-ce que ce projet a de plus de JNA, qui existe depuis des années pour remplacer JNI et qui fonctionne très bien et facilement en écrivant que du code java?le 19/06/2014 à 14:48
-
adiGubaExpert éminent séniorSalut,
Ils parlent de JNR et de la JEP 191 (Foreign Function Interface).
Je pense que cela se rapprochera du "Direct Mapping" de JNA, mais directement dans l'API et la JVM pour de meilleure performance.
Je ne sais pas comment cela fonctionne pour C#, mais il devra sûrement y avoir des types spécifiques pour cela...
Je ne pense pas qu'il s'agisse de permettre cela.
Le code Java ne contiendra toujours que du code Java, et rien d'autre !
Je pense que l'objectif consiste plutôt à éviter d'avoir à écrire (et compiler) du code natif pour utiliser une librairie native déjà compilé (*.dll, *.so).
Du coup le langage de la librairie importe peu si elle génère bien une librairie native...
a++le 19/06/2014 à 15:11 -
adiGubaExpert éminent séniorIls parlent de JNR.
Je ne connais pas vraiment mais il semble que c'est du JNA en plus poussé, avec plus de types gérés et surtout de meilleure performance.
Mais le gros intérêt serait d'avoir cela en standard, potentiellement optimisable par la JVM.
a++le 19/06/2014 à 15:21 -
GugelhupfModérateurLa manière dont il faut s'y prendre pour intégrer des modules bas niveau en Java avec JNI est compliqué, et je suis sur que beaucoup de développeurs attendent ce "JNI 2.0" avec impatience.
Cependant, j'aimerais beaucoup avoir un aperçu de l'intégration de ces modules bas niveau dans un programme Java.
Est-ce que ce sera comme en C# (avec des pointeurs etc...) ?
Est-ce pourra-t-on directement intégrer du code en ASM, C, ou C++ dans des blocs de code dans une méthode Java ? Ou est-ce que ce sera un langage "intermédiaire" (dans ce cas comment intégrer les projets ASM, C, C++, ADA existants) ?le 19/06/2014 à 13:52 -
GugelhupfModérateurMerci pour le lien adiGuba, je comprends mieux grâce aux exemples.
Ce sera un peu comme JNI 1.0 au niveau de l'appel de la méthode native en fait.
Ce qu'on peut remarquer par contre c'est que le mot-clé "native" n'est plus utilisé, et que pour les types "spéciaux" il faut utiliser une annotation Java sur le prototype de méthode.
Tout cela n'est pas déstabilisant, maintenant il faut voir la manip pour intégrer les ".so" & ".dll". J'espère juste qu'on n'aura une étape intermédiaire comme celui-là à coder :
Code : 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15/* DO NOT EDIT THIS FILE - it is machine generated */ #include <jni.h> /* Header for class TestJNI1 */ #ifndef _Included_TestJNI1 #define _Included_TestJNI1 #ifdef __cplusplus extern " C " { #endif JNIEXPORT void JNICALL Java_TestJNI1_afficherBonjour(JNIEnv *, jobject); #ifdef __cplusplus } #endif #endif
EDIT : J'espère juste qu'on n'aura PAS une étape intermédiaire comme celui-là à coderle 19/06/2014 à 16:00 -
adiGubaExpert éminent séniorL'objectif c'est clairement de ne plus avoir à écrire du code natif, comme on peut déjà le faire avec JNA ou JNR...
Après je pense qu'il faudra attendre encore pour avoir plus de détail sur la syntaxe précise.
a++le 19/06/2014 à 16:40