JCP lorgne le modèle open source

Le 21 mai dernier, lors d'une table ronde organisée par le groupe d'utilisateurs Java de Paris (Paris JUG), Patrick Curan a déclaré que l'ouverture de JCP, organisme de standardisation Java qu'il préside, ' était sans doute la prochaine étape ' dans l'évolution de l'organisation.

Aujourd'hui encore, le processus de validation d'une spécification Java (JSR) reste pour le moins laborieux et restrictif. Dix-huit mois sont en effet nécessaires pour obtenir l'approbation finale de l'organisme JCP, chargé de valider le processus étape par étape. Sans quoi le projet demeure en suspens jusqu'à nouvel ordre. Du coup, ' de plus en plus de projets se développent sans JCP ', explique Antonio Goncalves, architecte logiciel et expert au sein de l'instance JCP. A l'image des frameworks Hibernate et Spring, dont les concepteurs ont préféré court-circuiter l'organisme de standardisation de façon à ne pas freiner leurs développements.

La position de JCP se retrouvant amoindrie, ses membres militent désormais pour une procédure plus souple, comme l'explique Eric Samson, directeur technique de l'éditeur Xcalia et membre de JCP : ' Si une idée est proposée, il faut la laisser se développer sans barrières. La spécification viendra par la suite. C'est comme cela que l'on crée l'innovation et, ainsi, que l'open source avance. '

L'idée fait son chemin au sein de l'organisme JCP : développer, expérimenter, mettre en ?"uvre, et, enfin, spécifier si la solution est valable. Tout en conservant les étapes intermédiaires d'implémentation de référence (RI) et de kit de compatibilité technologique (TCK). L'enjeu est double : rassembler de nouveau les projets Java inspirés de l'open source, et attirer de nouveaux membres, indépendants des grandes sociétés, qui siégeraient dans les instances de décision de JCP. Devenant des ' spec lead ' (responsable dirigeant des spécifications), ils aideraient l'organisme, fondé par Sun en 1998, à retrouver plus de diversité. ' Trop souvent, les " spec lead " sont des sociétés, toujours les mêmes ?" BEA, Oracle ou IBM ?", qui tirent la couverture à elles, déplore Antonio Goncalves. En 2000, lorsque la spécification pour les Entity Beans était à l'étude, elle a été définie entre eux, sans qu'ils sinspirent de projets existants et éprouvés, tel Toplink, qui datait de 1995. ' La gouvernance de Java doit savoir prendre en compte un nouveau modèle atypique et tirer les leçons des erreurs passées.