J'ai porté près de 1,5 millions de lignes Cobol d'un logiciel de gestion financière de Cobol vers Java grâce à l'outil Open Source Naca et le résultat devrait rentrer ce mois ci en production dans de très grandes collectivités locales françaises pour la gestion de leurs finances.
Ce traducteur Naca génère exactement une ligne de code java pour une ligne de cobol, permettant ainsi à un programmeur Java de comprendre assez facilement de quoi il s'agit.
Le code généré est facilement tracable grâce aux outils log4j manipulables à distance via JMX permettant de tracer le runTime Naca jusqu'à l'affectation de chaque variable. Les performances sont tout à fait correctes et similaires à celles qu'on obtient en cobol. Par contre, l'approche une ligne cobol donne une ligne java rend très difficile une approche objet mais le traducteur aurait d mal à inventer ce qui n'existe pas au départ.
La solution OpenCobol avait été envisagée afin de s'affranchir des couts de runtime très élevées de la solution commerciale microFocus et le portage en OpenCobol puis tests montrent que cela fonctionne parfaitement bien pour peu d'avoir codé en Cobol standard. Ce qui a fait pencher vers une solution Java c'est qu'avec l'OpenCobol il y a obligation de maintenir le code Cobol car le code C généré est incompréhensible ce qui veut dire programmeurs Cobol qui sont rares sur le marché, facilité d'interopérer avec des briques java pour la solution Naca, tout le code traduit est tracable quasiment ligne par ligne.
Dans les deux cas, ce sont de très bonnes solutions OpenSource de qualité industrielle.
[^] # Re: Cobol to java
Posté par Jean-Max Reymond (site web personnel) . En réponse à la dépêche Le COBOL est mort, vive le COBOL. Évalué à 10.
J'ai porté près de 1,5 millions de lignes Cobol d'un logiciel de gestion financière de Cobol vers Java grâce à l'outil Open Source Naca et le résultat devrait rentrer ce mois ci en production dans de très grandes collectivités locales françaises pour la gestion de leurs finances.
Ce traducteur Naca génère exactement une ligne de code java pour une ligne de cobol, permettant ainsi à un programmeur Java de comprendre assez facilement de quoi il s'agit.
Le code généré est facilement tracable grâce aux outils log4j manipulables à distance via JMX permettant de tracer le runTime Naca jusqu'à l'affectation de chaque variable. Les performances sont tout à fait correctes et similaires à celles qu'on obtient en cobol. Par contre, l'approche une ligne cobol donne une ligne java rend très difficile une approche objet mais le traducteur aurait d mal à inventer ce qui n'existe pas au départ.
La solution OpenCobol avait été envisagée afin de s'affranchir des couts de runtime très élevées de la solution commerciale microFocus et le portage en OpenCobol puis tests montrent que cela fonctionne parfaitement bien pour peu d'avoir codé en Cobol standard. Ce qui a fait pencher vers une solution Java c'est qu'avec l'OpenCobol il y a obligation de maintenir le code Cobol car le code C généré est incompréhensible ce qui veut dire programmeurs Cobol qui sont rares sur le marché, facilité d'interopérer avec des briques java pour la solution Naca, tout le code traduit est tracable quasiment ligne par ligne.
Dans les deux cas, ce sont de très bonnes solutions OpenSource de qualité industrielle.