IdentifiantMot de passe
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Projet Panama : une future alternative à Java Native Interface fait son apparition
Pour offrir un interfaçage natif avec les API C et C++

Le , par Arsene Newman
6 commentaires

60PARTAGES

1  0 
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 ?
Vous avez lu gratuitement 613 articles depuis plus d'un an.
Soutenez le club developpez.com en souscrivant un abonnement pour que nous puissions continuer à vous proposer des publications.

Une erreur dans cette actualité ? Signalez-nous-la !

6 commentaires
Commenter Signaler un problème
tchize_
Avatar de tchize_
Expert éminent sénior https://www.developpez.com
Le 19/06/2014 à 14:48
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?
1  0 
adiGuba
Avatar de adiGuba
Expert éminent sénior https://www.developpez.com
Le 19/06/2014 à 15:11
Salut,

Citation Envoyé par Gugelhupf Voir le message
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 Voir le message
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 Voir le message
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++
1  0 
adiGuba
Avatar de adiGuba
Expert éminent sénior https://www.developpez.com
Le 19/06/2014 à 15:21
Citation Envoyé par tchize_ Voir le message
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++
1  0 
Gugelhupf
Avatar de Gugelhupf
Modérateur https://www.developpez.com
Le 19/06/2014 à 13:52
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) ?
0  0 
Gugelhupf
Avatar de Gugelhupf
Modérateur https://www.developpez.com
Le 19/06/2014 à 16:00
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 
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
0  0 
adiGuba
Avatar de adiGuba
Expert éminent sénior https://www.developpez.com
Le 19/06/2014 à 16:40
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++
0  0 
Commenter Signaler un problème