Migration RPG vers Java sur un IBM iSeries

Mon entreprise tente également de migrer vers Java à partir de RPG.

1. Nous n'essayons pas d'utiliser un JRE sur un client léger, nous passons à des applications Web livrées via un navigateur. Cela peut entraîner (éventuellement) le remplacement de nos anciens scanners POS par certains des plus récents sur PC.
2. J'ai été informé (par les architectes de la société) que la JVM sur le système d'exploitation iSeries a des problèmes de performances. Je ne sais pas personnellement quelles sont ces limitations. Dans notre cas où la migration a impliqué l'allocation d'une ressource AIX, ce qui est censé être beaucoup mieux - parlez à votre représentant IBM pour savoir si vous avez juste besoin d'acheter la licence du système d'exploitation (je programme juste sur la chose, je ne m'implique pas dans le matériel).
3. Voir la réponse à la question 1. Dans un contexte plus large, où vous essayez de mettre à jour le navigateur (ou toute autre ressource), cela est généralement géré par des licences d'entreprise - la plupart auront des options pour autoriser forcé, distant mettre.

Quelques autres notes:

• Vous devriez pouvoir passer à l'utilisation de.NET, bien que vous ayez peut-être besoin de de matériel/partitions différents pour exécuter l'environnement. Vous pouvez parler à DB2 de cette façon, au moins. Le seul avantage de Java est qu'il fonctionnera sur le même système d'exploitation/matériel que la base de données.
• J'ai vu une application screenscraper ici (c'était dans VB.NET, mais je suis assez sûr que l'exemple s'applique). Grattage d'écran a été réalisé par obtenir / placer des caractères à des positions spécifiques sur les écrans (l'équivalent de substring()). Cela pourrait être juste l'API que nous utilisions - je pense que j'ai entendu parler de solutions capables de lire les noms de champs. Cependant, il s'appuyait également sur le flux du programme RPG pour sa logique, et n'était autrement pas maintenable.
• La plupart des programmes RPG que j'ai vus et écrits ont tendance à être une violation de MVC, ce qui signifie que vous ne pouvez rien faire de moins que des tests d'intégration - l'histoire et l'architecture du la langue elle-même (et certains développeurs) préfère que tout (accès aux fichiers à l'écran) soit dans un seul fichier. Cela rendra également impossible toute tentative d'envelopper RPG pour appeler efficacement à distance. SI vous avez correctement séparé tout dans les programmes de service, vous devriez être en mesure de les envelopper (comme l'équivalent d'un appel de méthode native, presque) proprement-malheureusement, je n'ai rien vu ici qui n'ait pas tendance à s'appuyer sur une ou plusieurs astuces qui ne tiendraient pas utilisation Web typique (par exemple, utilisation d'un fichier dans QTEMP pour contrôler l'exécution du programme - la session sur iSeries disparaît effectivement chaque fois qu'une nouvelle page est demandée...).
• Java en tant que langage a tendance à promouvoir une meilleure séparation du code (notez qu'il peut être tout aussi mal utilisé), car il n'a pas tout à fait l'histoire du RPG. En général, il peut être utile de penser à Java comme un langage où tout est un programme de service, où tous les paramètres sont passés avec VALUE set, OPTIONS(*nopass : *omit) est interdit, CONST est généralement recommandé, et la plupart des paramètres sont de type DS (structure de données - c'est un type distinct dans RPG) et transmis par pointeur. Les paramètres au niveau du module sont mal vus, s'ils sont favorables à l'encapsulation de tout dans les structures de données passées ou les procédures du programme de service elles-mêmes. STATIC a une utilisation quelque peu différente en Java, rendant la variable globale, et n'est pas disponible à l'intérieur des procédures.
• RPG est un peu plus simple que Java, généralement, et la programmation OO est un paradigme tout à fait différent. Voici quelques éléments susceptibles de faire trébucher les développeurs migrant vers Java:
  1. Les tableaux dans RPG commencent à 1. Les tableaux en Java commencent à 0.
  2. Java n'a pas de paramètres 'ouput', et tous les types primitifs sont passés par valeur (copiés). Cela signifie que la modification d'un entier ne sera pas visible dans les méthodes d'appel.
  3. Java n'a pas d'encodage emballé/signé, et donc la traduction vers/à partir de nombres/chaînes est plus impliquée. date le type en Java a également de sérieux problèmes (il inclut le temps, en quelque sorte), et il est beaucoup plus difficile de changer de manière significative vers/à partir d'une représentation de caractère.
  4. Il est plus difficile de lire/écrire des fichiers en Java, même lorsque vous utilisez SQL (et oubliez d'utiliser des E/S natives directement avec Java) - cela peut cependant être atténué avec un bon framework.
  5. Il n'y a pas d'opérateurs ENDxx en Java, tout utilise des crochets ({}) pour spécifier le début/la fin des blocs.
  6. Tout dans Java est en freeformat, et il n'y a pas de spécifications en colonnes d'aucune sorte (bien que les signatures de procédure soient toujours requises). Il n'y a pas de hardlimit sur la longueur de la ligne, bien que ~80 caractères soient toujours recommandés. Les outils (les gratuits , même) sont meilleurs, point, et généralement beaucoup plus utiles (bien qu'ils puissent prendre un certain temps pour s'habituer à ceux qui sont exposés à SEU). Il existe également d'énormes bibliothèques gratuites disponibles en téléchargement.
  7. Le signe = n'est pas sensible au contexte dans Java comme il est dans RPG, il est toujours utilisé pour les affectations. Utilisez l'opérateur double-equals, == pour comparer les valeurs en Java.
  Les objets
  8. (structures de données) ne peuvent pas être comparés de manière significative à == - vous devrez souvent implémenter une méthode appelée equals() à la place.
  9. Les chaînes ne sont pas modifiables, elles ne peuvent pas être modifiées. Toutes les opérations effectuées sur des chaînes (soit sur la classe/structure de données elle-même, soit à partir de bibliothèques externes) renvoient de nouvelles références. Et oui, les chaînes sont considérées comme des structures de données , pas des types de valeur, vous ne pouvez donc pas non plus les comparer avec ==.
  10. Il n'y a pas d'équivalents intégrés aux directives de pré-compilateur /copy. Tenter de les implémenter utilise Java de manière incorrecte. Parce que ceux-ci sont généralement utilisés pour traiter le code "standard" (définitions de variables ou code commun), il est préférable de traiter cela dans l'architecture. Les variables (TOUTES LES spécifications D, en fait) seront traitées avec import ou import static les instructions, tandis que les variantes de code commun sont généralement gérées par un framework ou définissent une nouvelle classe.

Je suis sûr qu'il ya un certain nombre d'autres choses, laissez-moi savoir si vous avez d'autres questions.