Toutefois, toutes les expériences que j'ai eu avec des outils de traduction comme ça m'ont amené à penser qu'ils ne sont utiles que si on a vraiment pas le choix, et c'est rarement la meilleure solution. Le mieux c'est soit de réécrire, et d'en profiter pour repenser les applications (et le besoin ?), soit on garde l'existant.
J'ai souvenir d'un traducteur LISP vers Java... Le code est inmaintenable par la suite.
Et puis, je trouve bizarre l'idée de migrer COBOL vers Java. Une plateforme Unix n'est pas du tout comparable à un Mainframe. On n'y fait pas les choses de la même manière.
S'ils l'ont fait c'est qu'ils en avait besoin j'imagine, ou qu'ils ont cru en avoir besoin, mais ça me laisse perplexe.
Bon, je n'est pas regardé ce projet en particulier, peut-être qu'il est très bien quand même. Il n'y a pas des exemples de code traduit, histoire de se faire une idée ?
# faut voir
Posté par volia . En réponse à la dépêche Outils de transcodage COBOL vers Java du projet NACA publiés sous GPL/LGPL. Évalué à 4.
Toutefois, toutes les expériences que j'ai eu avec des outils de traduction comme ça m'ont amené à penser qu'ils ne sont utiles que si on a vraiment pas le choix, et c'est rarement la meilleure solution. Le mieux c'est soit de réécrire, et d'en profiter pour repenser les applications (et le besoin ?), soit on garde l'existant.
J'ai souvenir d'un traducteur LISP vers Java... Le code est inmaintenable par la suite.
Et puis, je trouve bizarre l'idée de migrer COBOL vers Java. Une plateforme Unix n'est pas du tout comparable à un Mainframe. On n'y fait pas les choses de la même manière.
S'ils l'ont fait c'est qu'ils en avait besoin j'imagine, ou qu'ils ont cru en avoir besoin, mais ça me laisse perplexe.
Bon, je n'est pas regardé ce projet en particulier, peut-être qu'il est très bien quand même. Il n'y a pas des exemples de code traduit, histoire de se faire une idée ?