Projet Panama : une future alternative à JNI fait son apparition pour offrir un interfaçage natif avec les API

Projet Panama : une future alternative à JNI fait son apparition pour offrir un interfaçage natif avec les API C et C++
Sans nécessité d’écrire un code spécifique

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 à :

• 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 ?

:fleche: Qu’en pensez-vous ?

La 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) ?

Et 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?

Salut,

Citation:

---

Envoyé par Gugelhupf

Cependant, j'aimerais beaucoup avoir un aperçu de l'intégration de ces modules bas niveau dans un programme Java.

---

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.

Citation:

---

Envoyé par Gugelhupf

Est-ce que ce sera comme en C# (avec des pointeurs etc...) ?

---

Je ne sais pas comment cela fonctionne pour C#, mais il devra sûrement y avoir des types spécifiques pour cela...

Citation:

---

Envoyé par Gugelhupf

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) ?

---

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++

Citation:

---

Envoyé par tchize_

Et 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?

---

Ils 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++

Merci 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à à coder

L'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++