Je vais vous raconter une petite histoire. Plus ou moins drôle, du côté où on se place.

Le monde des logiciels d’entreprises (et notamment des systèmes d’informations centralisés dont font partie les ERP) est dominé par plusieurs compagnies multinationales, dont SAP et Oracle. C’est deux là sont très importantes, et ressemblent plus à des Microsoft du marché professionnel qu’à des start-ups.

D’un côté, SAP, qui édite depuis longtemps tout un écosystème d’applications pour entreprises. Elles sont personnalisables via le langage « propriétaire » et « interne » à SAP : l’ABAP. QU’est-ce que l’ABAP ? Wikipédia nous répond :

ABAP est un langage de programmation propriétaire, faisant partie de l’ensemble logiciel SAP. Il s’agit actuellement du langage utilisé dans la programmation des Web Application Server faisant partie de la plateforme Netweaver pour la réalisation de progiciels.

L’ABAP est l’un des successeurs du COBOL et est apparu dans les années 1980 dans la vague des langages de quatrième génération (4GLs). Il s’agit d’un dérivé du langage permettant de réaliser des sorties de données (appelées rapports) de l’application SAP R/2, sur lequel de nombreuses multinationales avaient bâti leur architecture d’application professionnelle. L’ABAP a par la suite été maintenu comme langage de référence pour les applications SAP R/3 qui sont apparus en 1992.

Le langage a été par la suite étendu pour englober un modèle de données orienté objet (ABAP Objects) à partir de sa version 4.5, pour être finalement intégré comme langage d’un produit plus général appelé NetWeaver. Ce dernier utilise aussi bien l’ABAP que le Java.

La plateforme Netweaver ? Et oui, c’est une des plateforme que SAP met progressivement en avant dans l’ensemble de ses produits. Pourquoi ? Une des raison est peut-être là : le Java. Le Java ? Mais oui, souvenez vous ! Ce langage créé par Sun, maintenu par Sun, et progressivement adopté et reconnu par un grand nombre d’entreprises (notamment dans le début des années 2000) comme un langage assez stable et très pratique pour faire baisser les coups de production (car le développement est plus rapide, notamment grâce à des frameworks comme JEE).

Bref. Java, c’est standardisé, beaucoup de développeurs savent programmer avec, donc ça fait baisser les coups de production du code, et donc les entreprises clientes de SAP peuvent apprécier la possibilité de coder en Java pour personnaliser et adapter leurs produits SAP.

Sauf que : dernièrement, si vous vous souvenez bien, Oracle a racheté… Sun ! Donc par voie de conséquence, et même si Java est désormais sous licence GNU GPL, on peut considérer que Oracle détient Java… Or, si SAP accepte d’être codé en Java, ça voudrait dire que SAP est infiltré par son pire ennemi !

Donc, ce qui devait arriver arrive, et SAP va progressivement arrêter de passer leur produits au Java 🙁 . Pour être tout à fait honnête, là n’est pas la seule raison. En fait, il faut bien comprendre également qu’il y a un énorme problème de compatibilité entre le Java et l’ABAP, déjà très répandu au sein des entreprises. Notamment à cause du fait que sur SAP R3, tout est exécuté en ABAP, donc il faut à chaque fois que le code produit en Java soit généré automatiquement en ABAP… Or, SAP aurait calculé que cela couterait trop cher d’adapter l’intégralité des produits, et donc commencerait à faire machine arrière… Il faut rajouter à cela que SAP compte derrière lui toute une machine de certification des développeurs ABAP, ainsi que tout un écosystème de développement autour de l’ABAP, écosystème que la standardisation du Java viendrait chambouler.

Bref : pour plusieurs raisons, dont une raison concurrentielle, SAP va progressivement arrêter d’utiliser Java au sein de ses produits.