Eclipse sera un standard de fait de Java

Depuis sa création, Eclipse a choisi une voie parallèle en ce sens qu'elle n'est pas issue de la communauté officielle de Java, c'est-à-dire du JCP (Java Community Process). La tendance se confirme. Au point que beaucoup d'observateurs prédisent que les technologies propriétaires mises en ?"uvre dans Eclipse feront davantage figure de standards de fait de Java. Une façon, pour IBM, de s'accaparer le pouvoir de Sun sur le langage qu'il a créé. Les conséquences du caractère propriétaire d'Eclipse sont lourdes pour les entreprises, car il les enferme dans cette plate-forme.

Le premier exemple de technologie propriétaire dans Eclipse est celui, bien connu, des composants graphiques SWT (Standard Widget Toolkit). Contrairement à ce que pourrait laisser croire leur nom, ils ne sont pas standardisés. Si ce n'est par la communauté Eclipse. Car le monde Java a adopté Swing/AWT. Pourtant, la technologie SWT est plus performante que sa concurrente. Mais leur coexistence effrite sérieusement la portabilité des applications Java. C'est d'ailleurs l'une des raisons pour lesquelles Borland a tardé à basculer son outil de développement JBuilder sur Eclipse. Car cela représente un important effort de réingénierie pour l'éditeur. Et pose un problème de portage aux utilisateurs souhaitant migrer vers les nouvelles versions de JBuilder.

Deuxième exemple de technologie propriétaire, celui du client riche. D'un côté, RCP (Rich Client Platform) est propre à Eclipse. De l'autre, Netbeans s'appuie sur le standard Java SE. Là encore, le problème réside dans la non-portabilité de la technologie Java utilisée dans Eclipse. Car les applications développées avec RCP imposent son installation sur les postes utilisateur. Pourtant, il n'est pas rare que RCP soit employé pour créer des clients riches pour Java.

Troisième exemple, celui de la modélisation. ' Même s'il est très intéressant, EMF (Eclipse Modeling Frameword) diverge des préconisations de l'OMG (Object Management Group) ', regrette Kamal Youbi, directeur R & D de Netfective Technology, une société qui édite notamment des solutions de modélisation UML. Cette divergence se retrouve en matière de règles de transformation. C'est ainsi que la plate-forme a choisi deux langages propriétaires de transformation graphique. D'abord UMLX, pour compléter le langage QVT (Query View Transformations). Comme son nom ne l'indique pas, ce n'est pas un standard. Ensuite ATL, pour transformer des modèles. Ces deux exemples sont plutôt surprenants. Car Rational, qui copilote les projets de modélisation dans Eclipse, avait justement participé à l'harmonisation du langage UML en se ralliant à l'OMG. Mais Eclipse semble s'écarter de cet organisme de standardisation. Il n'est d'ailleurs pas le seul. Microsoft est toujours resté à distance de l'OMG, mais aussi de l'une de ses technologies clés, le langage UML.

Plus récemment, la fondation a dévoilé un nouveau projet. Baptisé Jazz, il vise à offrir une solution collaborative de développement logiciel, notamment pour répondre aux besoins grandissants des équipes de développeurs dispersés sur le plan géographique. Plus précisément, Jazz pourrait enrichir Eclipse en installant dans ses fonctions de base un référentiel dédié au développement logiciel. Une approche qui semble comparable à celle de Team Foundation Server, la brique de travail collaboratif intégrée dans Visual Studio 2005. Mais l'arrivée de Jazz n'est pas pour tout de suite. La première version alpha devrait voir le jour cet été. Il faudra donc patienter pour en profiter. C'est probablement à cette période que lon saura si la mise en ?"uvre de Jazz dans Eclipse est propriétaire. Les premières déclarations peuvent laisser penser le contraire. Car les concepteurs espèrent le faire communiquer avec des logiciels non basés sur Eclipse, y compris Visual Studio. Voilà qui marquerait un virage important dans le développement logiciel.