 L´affrontement des éditeurs Java bouscule la sacro-sainte portabilité des développements. Une tendance qui ne fait qu´empirer depuis de nombreux mois. La faute à la productivité !
La promesse originelle de Java est simple : écrire une seule fois une application et l´exécuter n´importe où. Elle se traduit théoriquement pour l´entreprise par des coûts de développement et de maintenance faibles : une seule technologie à maîtriser quelle que soit la cible du déploiement - poste client, serveur, périphérique mobile, etc. - et une seule application à maintenir plutôt que plusieurs versions compilées pour chaque plate-forme d´exécution.
Java en voie de dé-standardisation Tout cela n´est malheureusement que théorique. D´une part parce que le langage Java évolue. On ne peut donc pas exécuter une application utilisant des technologies Java dernier cri sur une ancienne machine virtuelle. D´autre part parce que la communauté Java a spécialisé différents frameworks incluant différentes technologies en fonction de la cible de déploiement. Java 2 Enterprise Edition (J2EE) côté serveur, Java 2 Mobile Edition (J2ME) pour les périphériques mobiles, et Java 2 Standard Edition (J2SE) pour les postes clients.
Des dissensions prononcées 
Les dissensions actuelles entre les éditeurs Java n´ont jamais été aussi prononcées. Côté serveur, par exemple, tous les éditeurs proposent leur propre framework maison qui s´installe au dessus de J2EE pour accélérer les développements. C´est le cas par exemple de Oracle Application Development Framework (ADF) et de Beehive de BEA. La communauté Open Source n´est pas en reste avec des frameworks tels que Spring, Struts et consorts. L´apparition de ces frameworks hors norme - au sens où ils ne sont pas standardisés par le Java Community Process (JCP) - est censée compenser la complexité et les lacunes de J2EE. Un objectif qu´ils atteignent tous. Mais ils imposent d´utiliser l´outil de développement associé : JDeveloper pour Oracle ADF, WebLogic Workshop de BEA pour Beehive, etc. Malgré l´ouverture de Beehive et la possibilité théorique pour n´importe quel éditeur concurrent de l´intégrer à ses outils, on imagine mal Oracle privilégier ce framework plutôt que le sien.
Choisir son camp entre Oracle, IBM et BEA 
"On ne peut vraiment gagner en productivité qu´en s´appuyant sur un framework de haut niveau et l´outil de développement fermé qui l´accompagne. Dans les faits, cela revient à choisir son camp entre Oracle, IBM et BEA", résume Didier Girard (photo), directeur technique d´Improve. D´autre part, la présence de ces frameworks propriétaires est requise sur le serveur lors du déploiement de l´application qui les utilise. Une entreprise devra donc installer et maintenir plusieurs frameworks propriétaires si elle souhaite déployer des logiciels développés par différents éditeurs avec ces différents outils. Sans compter les nombreuses dépendances à gérer. Beehive de BEA s´appuie par exemple sur le framework Open Source Struts. Les risques de désynchronisation entre versions sont donc importants.
Lire la suite de l´article.
|