Java Open Source : ce qui va changer

Interview de Guillaume Bodet, directeur technique de Xebia

Quel sera l'impact d'un Java en GPL sur le quotidien des développeurs ? Le point sur la question avec Guillaume Bodet, directeur technique de Xebia, cabinet de conseil et de développement spécialisé en Java.

A qui cette annonce est-elle destinée à votre avis ?
La première cible est la communauté Open Source, notamment Linux, d'où le choix de la GPL plutôt que la CDDL, par exemple [licence d'OpenSolaris, NDLR]. Cela correspond à une envie de Sun de voir Java intégré plus étroitement aux distributions Linux. On devrait à terme arriver à des distributions dédiées à Java, alors qu'aujourd'hui, la machine virtuelle Java n'est pas optimisée pour Linux. Pour des applications serveurs, on conseille même plutôt celle d'IBM que celle de Sun, qui souffre d'instabilité chronique. La GPL permettra aux contributeurs d'optimiser la JVM pour cette plate-forme. Peut-être même arrivera-t-on à des distributions spécialisées, avec une JVM optimisée, voire intégrée au noyau, comme on trouve des distributions orientées sécurité, bureautique, etc.
La deuxième cible, ce sont les opérateurs télécoms. Ils ont un grand nombre de plates-formes pour lesquelles il faut construire des JVM. Nokia et Motorola ont des projets dans ce domaine. L'annonce devrait d'ailleurs couper l'herbe sous le pied de Motorola, qui veut établir une communauté autour de Java ME [sous licence Apache, NDLR].

Quels avantages cela présente-t-il pour les développeurs ?
La JVM de Sun souffre depuis le début d'un support assez déficient. La gestion de bugs soumise à un système de vote, cela a l'air bien, mais dans les faits... On aimerait pouvoir payer un service de support, mais ce n'est pas possible. Une ouverture permettra de corriger plus rapidement les bugs, sachant qu'il y en a qui sont signalés depuis cinq ou six ans. Cela devrait donc améliorer la qualité générale. Sinon, pour le travail du développeur, cela ne devrait pas changer grand-chose, tout ce qu'on utilise est public depuis longtemps. Il n'y aura pas de grande révolution au quotidien.

Le passage en GPL ne risque-t-il pas de susciter des craintes chez vos clients ?
Pour la plupart des développements en Java, une licence binaire est suffisante. Quant aux développements internes aux entreprises, ils ne sont jamais concernés par le côté viral de la GPL. Pour les éditeurs, il faudra réfléchir davantage sur le choix de la licence. Mais le recours à l'exception Classpath est très bien, cela règle le cas de 90% des applications Java, puisque globalement, les applications Java sont clientes de la JVM. Il ne restera que quelques cas spécifiques d'applications intégrées à la JVM.

Ce passage en Open Source présente-t-il des risques sur l'intégrité du code ? Verra-t-on des bifurcations (fork) ?
Le caractère viral de la GPL protège plutôt bien, je crois, contre les risques de fork. Et puis qui pourrait prendre sur soi l'initiative de forker un projet aussi gigantesque ? A part IBM, peut-être, personne n'y aurait vraiment intérêt. Cela ne devrait pas arriver. Sauf bien sûr si Sun fait l'erreur de ne pas mettre en place une gouvernance de projet satisfaisante.

Comptez-vous adhérer à OpenJDK ?
Je verrai comment cela s'organise. Etant à titre personnel très intéressé par les évolutions du langage, s'il y a moyen d'adhérer à une communauté qui influe sur ces évolutions, j'y adhérerai probablement.

Sun pouvait-il aller plus loin ?
Il reste des doutes sur la façon dont Sun va gérer le projet. Il reste propriétaire de la marque, ce qui peut poser des problèmes. On se souvient que JBoss a interdit à Geronimo d'utiliser des bibliothèques, libres mais nommées JBoss, en jouant sur la marque déposée. Sun conserve donc des arguments juridiques pour interdire potentiellement l'utilisation de Java.

Et le fait que le JCP reste en-dehors de cette annonce ?
Il y a des critiques assez fortes sur le pilotage du JCP, mais je ne les partage pas. Sun a réussi à maintenir une cohésion avec le JCP. Même s'il n'est pas parfait, il est relativement transparent, et finalement plus efficace que des organismes de ce type, chargés de définir des normes ? Certains auraient aimé que le JCP passe sous une gouvernance de type Apache ou Eclipse, mais je pense que cela n'est pas souhaitable. Apache et Eclipse font des produits, pas des normes. Et quand vous regardez les organismes qui définissent des normes, vous avez le modèle type OMG, usine à gaz, avec un important retard de phase, ou OpenSOA, qui n'est pas très transparent, et livre des spécifications toutes faites. Le JCP ne fonctionne pas si mal, finalement. On peut même dire qu'il a accompli un boulot plutôt spectaculaire depuis dix ans. Il y a des ratés (la partie persistance, par exemple), mais surtout des succès.