Discussion :

[Arsene Newman]

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 ?

Qu�en pensez-vous ?

[Gugelhupf]

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

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

[adiGuba]

Salut,

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.

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

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

[adiGuba]

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

[Gugelhupf]

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 :

S�lectionner tout - Visualiser dans une fen�tre � part

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

[adiGuba]

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