Java : La fondation Apache démissionne officiellement du JCP
Deux jours après le vote du comité exécutif du JCP, validant la feuille de route de Java 7 et 8, la fondation Apache met sa menace à exécution et démissionne de l’organisme. Une décision lourde de sens qui vient cristalliser véritablement les tensions qui existent depuis 2006, clarifiant ainsi la situation auprès des développeurs.
La fondation Apache a officiellement annoncé sa démission du comité exécutif du JCP (Java Community Process), l’organisme en charge de la gouvernance de Java ce 9 décembre. Tournant ainsi le dos à Oracle et à l’ensemble des autres membres du comité qui, selon la fondation Open Source, “ont échoué” sur deux points. “ Les membres du comité exécutif ont refusé de faire valoir les droits des intégrateurs et, en acceptant les termes de la licence du TCK d’Oracle pour Java SE 7, ont laissé la structure de licence du JCP se briser”, écrit la fondation sur son blog.
Pour mémoire, le 7 décembre, les membres du comité exécutif ont approuvé la feuille de route de Java SE 7, définie par Oracle, en dépit des pressions de la fondation Apache, qui demandait aux membres du comité de purement bloquer le processus en votant contre le projet d’Oracle. La fondation Apache avait alors placé en vain dans la balance sa démission du comité exécutif, si toutefois le vote était favorable à Oracle. Ce qu’il fut. “Ce vote représentait le seul pouvoir dont disposait le comité exécutif en tant qu’organisme de gouvernance des spécifications de Java et de son éco-système […]”, souligne aujourd’hui la fondation. Sa dernière chance, en somme.
La réaction d'Oracle |
Oracle n’a pas tardé à réagir, de façon très politique. Dans un billet de blog, Adam Messinger, vice président du développement demande à la fondation de faire machine arrière. “Nous encourageons Apache à reconsidérer sa position et à rester au sein du processus d’évolution de Java. ASF, ainsi les nombreux projets Open Source qu’elle héberge, jouent un rôle capital dans tout l’éco-système Java.” Le groupe explique qu’il est de “sa responsabilité de faire progresser Java” et “de maintenir une unité parmi les standards Java” pour les millions de développeurs. |
Cliquez pour dérouler |
Le combat de la fondation Apache ne date pas d’hier. Elle reproche à Oracle - et auparavant à Sun - de ne pas lui céder une licence du TCK (Technical Compatibility Kit) afin qu’elle puisse certifier Harmony, un projet d’implémentation Open Source de Java. Une licence que la fondation estime limitée, notamment via les conditions d’utilisation (FOU - Field of Use) : selon elle, les termes de la licence violent les termes du JSPA (Java Specification Participation Agreement - qui définit les termes d’utilisation de Java) en n’étant pas disponible à l’Open Source. Un JSPA que “le JCP n’est pas parvenu à protéger”, commente aujourd’hui la fondation.
Dans son billet de blog, la fondation pointe du doigt l’organisme en indiquant qu’il ne suit pas “un processus ouvert de spécifications”. “Les préoccupations commerciales d’une unique entité, Oracle, ne cesseront d’interférer sur le processus de gouvernance transparent de l’écosystème”, explique-t-elle, et “il est désormais impossible de distribuer des implémentations indépendantes des JSR sous licence Open Source”. Notons toutefois qu'une implémentation libre sous licence GPL de J2SE existe sous la forme d'OpenJDK, l'implémentation libre de Java utilisée par les distributions Linux les plus courantes.
Depuis le rachat de Sun par Oracle, le JCP a perdu certains de ses membres influents, à l’image de Doug Lea qui a ouvertement protesté contre l’attitude d’Oracle. “J’estime que le JCP n’est plus crédible tant en matière de spécifications que d’organisme de standardisation et qu’il n’y a plus d’intérêt pour un défenseur indépendant de la communauté académique et universitaire d’y siéger”, avait-il alors déclaré.
Apache est l’un des plus grands havres de projets Java Open Source. La fondation Open Source héberge quelques 70 projets, dont certains sont très populaires. Citons Hadoop, Tomcat, Cassandra et Geronimo. Quelque 30 projets sont actuellement placé dans son incubateur (une étape avant d’atteindre le rang de projet, selon la gouvernance de la fondation). Des milliers de contributeurs sont également impliqués.
Pas d’inquiétude, côté développpeur
Pour Bertrand Delacrétaz, membre de la fondation Apache qui s’exprime en son nom propre - développeur Java pour la société Day Software, rachetée par Adobe -, les développeurs Java ne doivent pas s’inquiéter. Car finalement, l’avenir et les évolutions de Java, les versions 7 et 8, ont peu d’importance. “En tant que programmeur java, au delà de Java 5, les évolutions du langage et de la plate-forme ne nous intéressent pas vraiment. […] Si je veux un langage plus moderne, j’en prendrai un autre qui tourne tout aussi bien sur la JVM”, explique-t-il, tout en ajoutant que nombre de développements sont aujourd’hui réalisés dans plusieurs langages. Et de citer Javascript côté-serveur et JRuby. Autrement dit , avec cette conception multi-langage sur la JVM, Java n’est presque plus indispensable.
“Pour les développeurs, ce qui important est d’avoir des VM performantes. En revanche , c’est par là que le changement pourrait arriver ; si Oracle se décidait à rendre payant la VM. Mais au risque de détourner les utilisateurs”, ajoute-t-il.
Une rivalité exposée et claire
Bertrand Delacretaz pense d’ailleurs que cette démission “n’est pas un mal” en soi, car elle clarifie, auprès de l’éco-système et des entreprises, ce qui existe depuis plusieurs années dans le JCP. “Dans les faits ça change rien, sauf qu’il est désormais clair pour tous que c’est Oracle qui tire les ficelles. Mais cela n’a pas changé depuis 2006, date de notre dispute avec Sun. Aujourd’hui les choses sont plus claires, commente-t-il. “Aujourd’hui, en voyant que Java n’est pas complètement ouvert, les développeurs réfléchiront peut-être à se tourner vers autre chose.”
Finalement, conclut-il en substance, avons nous encore besoin d’un organisme de normalisation ? “Pour une faire spec, j’ai besoin d’une classe d’API et d’une suite de test. On pourrait très bien le faire dans des projets Open Source, sans comité de normalisation. La gouvernance et les bonnes pratiques d’Apache pourraient s’appliquer à créer des specs.”