Quelques règles à  appliquer

de service, vos clients
Java peuvent facilement accéder à  ce
code, comme le montre la figure 1.
L’architecture RPG existante montre
qu’un programme client RPG invoque
les sous-procédures Subprocedure A
et Subprocedure B d’un programme
de service RPG. L’architecture Java/
RPG montre qu’en offrant un programme
de service RPG validé JNI
middleware, les clients Java peuvent
utiliser la fonctionnalité de la sousprocédure
A et de la sous-procédure
B dans le programme de service RPG
existant. Les sous-procédures (SubprocedureAJNI,
SubprocedureBJNI et
Subprocedure CJNI) dans le programme
de service RPG validé JNI sont des
emballages minces qui agissent
comme un conduit entre Java et RPG,
donnant à  Java l’accès aux sous-procédures
(SubprocedureA, SubprocedureB
et SubprocedureC, respectivement)
dans le programme de service
RPG existant.
Les sous-procédures RPG que Java
invoque sont connues en tant que
méthodes natives, et JNI exige que
leurs prototypes utilisent une syntaxe
spécifique avec des mots-clés spéciaux.
Plus précisément, vous spécifiez
le mot-clé ExtProc en utilisant le
format:

ExtProc( *Java: YourClass: YourMethod )

où YourClass est la classe Java contenant
la méthode native Java identifiée
par YourMethod. Nous examinerons
de plus près ce mot-clé ultérieurement.
Comme ses types de données diffèrent
de ceux que l’on trouve en RPG,
Java a aussi besoin d’une conversion
de données. Et cela que l’on utilise JNI
ou une autre technique pour l’intégration.
Le tableau de la figure 2 classe en
deux groupes les types de données
Java et leurs types RPG correspondants.
Le premier groupe affiche les
types de données pour lesquels il
existe une association directe entre un
type de données RPG et un type de
données Java. Ce sont les types de données
Java primitifs et ils incluent le type
d’indicateur et un sous-ensemble des
types de données numériques supportés
par RPG. Le second groupe montre
qu’il n’y a pas d’association directe
entre les types de données caractère,
date, heure et timestamp de RPG et
leurs contreparties Java qui sont des
objets. Si nécessaire, il faut convertir
ces types. D’après notre expérience, il
est plus naturel d’effectuer la conversion
côté Java que de forcer les développeurs
RPG à  manipuler des objets
Java et les méthodes Java pour extraire
l’information de ces objets. En regardant
de plus près le tableau de la figure
2, on voit que Java ne supporte
pas tous les types de données que RPG
supporte (packed, zoned, binary, unsigned,
par exemple). Il existe des objets
et des méthodes Java pour les convertir
également.
Enfin, les sous-procédures RPG validées
JNI (méthodes natives) doivent
passer les types de données primitifs
Java (le premier groupe de la figure 2)
par valeur et doivent passer les objets
(le second groupe dans la figure 2) par
référence. Comme vous ne pouvez pas
définir byte [ ] et char [ ] Java en longueur
fixe, vous devez utiliser le motclé
Varying pour des données UCS-2
dépassant un octet (défini comme nC)
et pour des données caractère dépassant
un octet (défini comme nA).