Depuis quelques mois, le monde Java est en ébullition. Le rachat de Sun par Oracle suscite inquiétude et hostilité. Un certain nombre d’observateurs ont prédit dès le rachat des changements annonçant la fin de la communauté open source autour de Java.Les événements récents comme le procès d’Oracle contre Google ou l’alliance avec IBM précipitant l’arrêt du projet Harmony, semblent conforter ce point de vue. Bref, aujourd’hui la tension dans la communauté Java est très forte et le ressenti a l’égard d’Oracle devient de plus en plus palpable. Tout est réuni pour qu’une guerre sanglante éclate au sein de l’univers Java. C’est un scénario digne d’une véritable épopée homérienne qui semble se dessiner sous nos yeux. Mais les choses sont-elles aussi simples et manichéennes qu’une majorité d’individus dans la communauté semble le penser ? Pas si sûr. Remettre les événements en perspective et prendre un peu de hauteur semble la première chose à faire pour analyser sereinement la situation.
Java l’exception logicielle
Java est une plateforme à part. Pas seulement d’un point de vue technique mais surtout par son historique qui explique aujourd’hui les antagonismes autour de celle-ci. Avant de détailler les batailles actuelles, revenons sur ces particularités.
Une plate-forme, un Langage et un environnement d’exécution
L’appellation “Java” est depuis l’origine source de confusion. En effet, Java c’est d’abord un langage de programmation, mais aussi une plate-forme (en fait 3 plate-fomes enrichissant le langage de nombreuses technologies et bibliothèques) et un environnement d’exécution (la machine virtuelle). Quand on parle de Java, il arrive fréquemment que chacun ait en tête des aspects différents lié au nom “Java” ce qui créé souvent des mal entendus lorsque l’on discute de Java.
Les 3 plate-formes Java
Lorsqu’on parle de la plate-forme Java, cela peut désigner en fait 3 plate-formes :
- Java SE (Standard Edition), la plateforme de base ;
- Java EE (Enterprise Edition) : plateforme permettant des développements d’entreprise en ajoutant à SE des spécifications de technologies comme Servlet, JTA ou JSP qui sont très majoritairement utilisées lors de développements Web ;
- Java ME (Micro Edition) : plate-forme conçues pour la mobilité en allégeant certains aspects de Java SE et en ajoutant des technologies nécessaire aux appareils mobiles.
Java SE est souvent la plate-forme que l’on évoque lorsque l’on parle de plate-forme Java. Toutefois, on utilise très fréquemment une partie des spécifications issues de Java EE (JPA, JSP, JTA, Servlet). Java EE (s’appuyant sur Java SE) est donc le socle (enrichi bien souvent d’autres technologies, comme Spring ou Guice) de la grande majorité des développements aujourd’hui. Il est communément admis aujourd’hui que Java ME est en panne (pour rester politiquement correct) mais nous reviendrons la-dessus plus tard.
Le JCP : une approche collégiale, très critiquée
Peu après le lancement de Java, en 1995, Sun Microsystem comprit rapidement que le succès de celui-ci nécessitait le partage de la gouvernance de la plateforme avec d’autres éditeurs. C’est l’idée directrice qui amena Sun à créer le JCP (Java Commuity Process) en 1998. Ainsi très rapidement les orientations autour de Java furent prises de manière collégiale.
Cependant à ses débuts, le JCP n’offrait pas le même niveau d’ouverture qu’aujourd’hui et seuls de gros acteurs purent prendre part à cette collégialité. C’est probablement la principale raison des échecs du JCP : avoir privilégié le point de vue de gros éditeurs qui poussèrent des technologies plus que discutables. L’exemple le plus évident de ce dysfonctionnement est probablement les spécifications EJB 1.X (et EJB 2.X) qui boostèrent le développement de solutions parallèles dans la monde de l’Open Source comme les frameworks Spring et Hibernate (pour plus de détail lisez “Les rendez-vous manqués de Spring” qui décrit cette histoire).
Cependant, le JCP a su corriger ses erreurs en se démocratisant et en s’inspirant de solutions du monde l’Open Source qui marchent pour les nouvelles spécifications. Cette évolution, qui permit de délivrer des spécifications largement adoptées comme JPA ou EJB 3.X, ne permit pas en revanche de complètement laver l’image du JCP qui reste aujourd’hui décriée par un certain nombre d’acteurs. Parmi ceux-ci, on retrouve ceux qui ont construit leur business sur les errements du JCP (comme Spring Source) et qui n’ont franchement pas intérêt à ce qu’un JCP vertueux vienne créer des spécifications concurrentes de leur solution.
Si le JCP d’aujourd’hui est plus performant et ouvert qu’à ses débuts, il reste des choses à améliorer, notamment sur le front de la démocratie car le propriétaire de Java (Oracle) garde une place privilégiée au sein de l’organisation et reste juge et partie concernant bien des arbitrages. Il n’empêche qu’aujourd’hui le JCP est l’un des éléments qui rend Java si particulier et quoi qu’on puisse en dire participa grandement à l’adoption de la plateforme Java.
En résumé, le JCP pour Java c’est un peu comme l’ONU pour la gouvernance mondiale. Il n’est pas parfait, commet des erreurs, créé de la lenteur mais permet à la grande majorité des acteurs autour de Java de se mettre autour d’une table et de travailler en commun. Mon avis est que sans le JCP, java serait une plateforme de développement comme les autres et qu’une multitude de technologies différentes et incompatibles entre elles auraient vu le jour sans que se dégage un consensus sur les briques de base.
Java en liberté surveillée
Pour clore ce point sur les particularité de Java, il me semble important de rappeler le statut de la plate-forme en terme de licence logicielle. Aujourd’hui Java est Open Source mais le nom Java reste la propriété d’Oracle et surtout la conformité d’une implémentation de Java ou de spécification Java EE (les fameux TCK) reste payante et d’un coût très élevé. Ainsi, Java est libre, mais l’entité qui voudra livrer une version de Java compatible avec les spécifications du JCP devra payer ce droit. On est donc clairement à mi-chemin entre le libre et le propriétaire.
Les forces en présences
Mais revenons à notre “guerre” larvée et intéressons-nous aux forces en présence
Oracle
Le méchant de l’Histoire. Fondé en 1977, Oracle n’est pas ce qu’on pourrait appeler une entreprise issue des nouvelles technologies mais un dinosaure de l’informatique de gestion qui a su au fil des décennies s’adapter aux changements et prospérer grâce à son moteur de base de données.
Cette culture tranche vraiment avec celle de Sun Microsystem (plus dans la mouvance Hippie) qui fut à l’origine de Java et qu’Oracle a racheté l’année dernière. Ce clash culturel a généré beaucoup de craintes (fondées ou non) autour de l’avenir de Java. Ainsi, même sans entreprendre aucune action (au delà du rachat de Sun), Oracle mettait déjà en émoi la Javasphère.
Si l’entreprise semble préférer mettre en avant son service juridique plutôt que sa R&D, il faut quand même lui reconnaitre qu’un certain nombre de contributions dans le monde de l’Open Source comme Eclipselink (ex Toplink), Berkley DB ou Xen.
Pour résumer l’attitude d’Oracle : ils n’ont pas absorbé Sun par philanthropie et comptent bien gagner de l’argent avec Java.
En moins de 15 ans d’existence, Google a su monter un empire en trustant le marché de la publicité en ligne. Société de geeks et de développeurs (pas grand chose à voir avec Oracle), elle est l’ami de tous les technophiles. Les nombreux produits gratuits qu’elle distribue ont fait sa renommée et sa puissance. Google est à même d’imposer au marché des technologies et des outils sans que cela apparaisse comme de la conquête de part de marché et de l’éviction de société concurrentes. Effrayante et fascinante Google est dans une position assez unique dans le monde.
Sur le front de Java qui nous intéresse, Google est en quelques années devenu un acteur majeur de la communauté. Outre ses contributions à travers des bibliothèques Open Source comme Guava ou des frameworks comme Guice, Google est surtout l’instigateur d’une plate-forme Java pour le Cloud (Google App Engine) et de la fameuse plate-forme mobile Android qui a déchainé les foudres d’Oracle.
Ces deux dernières contributions conséquentes ont été élaborées en contournant le JCP. GAE constitue clairement une version propriétaire de Java EE (certaines API Java sont acceptée ou non selon le bon vouloir de Google) ce que Microsoft fit à la fin des années 90 avec nettement moins de popularité et un procès perdu. Quant à Android, c’est Java ME repensé de 0, là encore sans passer par la case JCP et une concertation avec la communauté (motivation supplémentaire dans le procès d’Oracle contre Google). Cela n’ôte rien à la qualité et l’intérêt de ces technologies, mais force est de constater que Google utilise le travail du JCP pour créer un environnement propriétaire sans renvoyer l’ascenseur et se soucier des concepts de base de la plate-forme (run everywhere).
Une forme de squat en quelque sorte, mais un squat super sympa où on se permet d’inviter tous ceux qui veulent à un buffet gratuit. C’est en fait un copier coller de la stratégie de Google consistant à s’approprier un contenu (comme la numérisation de livre sans l’accord des éditeurs) et de diffuser ce contenu gratuitement. Le consommateur L’utilisateur final est ravi, et le propriétaire de contenu spolié est montré du doigt comme un grincheux en retard sur son époque.
La fondation Apache
Créée en 1994, cette fondation pour le logiciel libre s’est délibérément orientée vers la technologie Java depuis la fin des années 90. Elle édite le serveur Tomcat qui implémente un sous ensemble minimal de Java EE et sert de base à une grande partie des développements répondant à un autre standard que Java EE comme Spring notamment.
L’autre projet Apache, sous les feux des projecteurs depuis plusieurs semaines c’est Harmony, une implémentation de la plate-forme Java SE qui sera probablement une des victimes de la bagarre actuelle comme on le verra plus loin.
IBM
On a gardé le meilleur pour la fin. Si j’ai utilisé le terme “Dinosaure” pour Oracle, que dire d’IBM dont la fondation remonte à 1896 ? Cette entreprise qui a vu naître l’informatique, n’a clairement pas la culture Internet dans ses gênes, toutefois, elle a su traverser les âges et les évolutions technologiques en prospérant jusqu’à devenir le géant qu’elle est aujourd’hui.
La taille de son catalogue logiciel, matériel et de service est sans commune mesure avec un autre acteur du marché et les multiples doublons de produits et d’offres qu’il comporte amène parfois Big Blue à avoir des comportements contradictoires et difficilement compréhensible de l’extérieur.
Au dela de cet aspect un peu brouillon, IBM reste l’un des acteurs les plus actifs de l’Open Source. Que ce soit sur Linux, Eclipse ou les dizaines de projets open source pilotés, initiés ou financés par IBM, la société déploie des ressources colossales dans l’écosystème Open Source mondial.
Autant dire que quand IBM prend en main un projet, celui-ci peut prendre un essor incroyable ou être réduit en poussière en quelques années sans que l’on sache toujours pourquoi. Les aficionados d’OS/2 dans les années 90 savent de quoi je parle.
Cette image un peu flou autour d’IBM et son incapacité à communiquer clairement sur une stratégie compréhensible par le commun des mortels autour de ses produits, alimente clairement l’inquiétude de la communauté Java à l’annonce du ralliement de Big Blue à Oracle dans le support d’OpenJdk et donc l’abandon (ou du moins la mise en péril) d’Apache Harmony qu’IBM sponsorisait jusqu’ici.
Pourquoi ça bouge ?
En fait, la bonne question serait plutôt “pourquoi ça n’a pas bougé plus tôt ?”. Ces dernières années, un certain nombre de chantiers dans l’univers Java étaient au point mort à cause de la situation de faiblesse financière dans laquelle se trouvait Sun. Durant cette période où Sun était dans la plus grande difficulté pour assumer son rôle de pilote, le monde Java s’est un peu développé de manière anarchique créant des choses intéressantes (Android et GAE notamment) mais aussi pas mal de cacophonie.
La période du rachat par Oracle ralentit encore plus les évolutions des différentes plate-formes en créant beaucoup d’attentes. Enfin, le mélange détonnant de la culture Oracle dans celle de Sun créa également de grosses tensions avec son lot de démissions et de restructurations et occasionna de nouvelles pertes de temps.
Mais après cette phase de prise de contrôle, Oracle a manifestement décidé de siffler la fin de la récré et de passer à l’action en prenant comme première cible Google.
Les fronts du combat
Java ME
C’est donc sur Java Micro Edition qu’Oracle a choisi d’ouvrir les hostilités. Comme évoqué plus haut,cette Edition de java est en panne depuis plusieurs années et n’a pas vraiment bonne presse chez les développeurs.
Lorsque Google décide de lancer Android en 2007, ils écartèrent Java ME (l’histoire ne dit pas clairement s’ils envisagèrent de l’utiliser) et décidèrent de partir de zéro en créant leur propre version de Java : Dalvik qui est une sorte de fork de la JVM. Android propose dans son SDK une grande partie des API de Java SE enrichi d’OpenGL ES en provenance de ME et d’autres API ou outils assez fréquents dans les développements Java (SQL Lite, Junit ou Commons Codec entre autres). Le cocktail final est bien plus riche que ME et propose donc une plateforme cohérente qui vient concurrencer ME.
A la suite de l’annonce d’Android, Sun n’eut pas la réaction attendue par les analystes. Le CEO de Sun salua même Google dans un billet sur son Blog “Congratulations Google“. Cette non réaction de Sun fut imputée à l’état de faiblesse de la société et à un constat de l’impasse dans laquelle était enferrée Java ME.
Mais Oracle allait revenir sur ce dossier dès l’acquisition de Sun bouclée. Je ne vais pas décrire ici les hostilités entre les deux géants, un petit coup d‘Oracle contre Google dans… Google 😉 devrait vous permettre de rattraper les épisodes si vous étiez dans une grotte depuis le mois d’août.
L’issu de ce combat est incertaine et les arguments en faveur des deux géants sont recevables, cependant je m’abstiendrai de hurler avec les loups contre Oracle et me rangerai à l’avis du Touilleur sur ce point : Il est légitime qu’Oracle défende son produit et ça ne ferait pas de mal à Google de passer par le tiroir caisse pour s’être appuyé sur une techno et une communauté qui à la base n’est pas la leur (le fameux Squat cool).
Java SE
Le front Java SE contre Apache Harmony n’a pas été ouvert par Oracle, mais par Sun qui n’a jamais fait les adaptations nécessaires à la licence du TCK pour permettre à Apache d’en bénéficier sur son implémentation de Java.
Harmony constitue donc une distribution de Java qui ne peut pas s’appeler “Java” et ne peut pas être certifiée comme telle. Toutefois le projet avait un contributeur et un allié de taille : IBM. En froid avec Sun sur bien des points et notamment la gouvernance de Java, IBM contribuait à Harmony pour participer à un concurrent du projet Open JDK lancé par Sun.
Oracle s’est contenté de retourner IBM et de vider Harmony d’une grande partie de ses développeurs. En échange Oracle aurait donné à IBM des garanties concernant le JCP dont le détail n’a, à ma connaissance, pas encore filtré.
Résultat, Harmony est en grosse difficulté et si un acteur majeur ne vient pas à son secours, a de forte chance de mettre la clé sous la porte. Tout ça au profit du projet Open JDK, lui aussi Open Source mais piloté par Oracle.
La communauté Java s’est beaucoup émue de cette passe d’arme et la fondation Apache ne l’a pas encore digérée. A tel point que l’organisation a annoncé le 9 novembre son départ du JCP (après une réélection à 95% des voix). Oracle ne cherche manifestement pas à brosser les développeurs dans le sens du poil mais à rassurer les décideurs en s’alliant avec Big Blue et en tentant de redonner de la cohérence et du pouvoir à la gouvernance autour de Java.
La question qui reste en suspend c’est : est-ce qu’un acteur conséquent viendra s’opposer à cette mise au pas en ré-injectant des ressources dans Harmony ? Certains souhaitent que Google joue ce rôle, mais je ne suis pas sûr de saisir l’intérêt qu’ils pourraient avoir à le faire.
Java EE
Pas de front de ce côté là pour le moment, mais je me permets de faire quelques conjectures (histoire d’être ridicule plus tard).
Depuis presque un an Java EE 6 propose enfin une stack cohérente pouvant entrer en concurrence directe avec les solutions de contournements développées ça et là pour palier aux manquements passés de Java EE (j’ai réussi à ne pas citer Spring). Les éditeurs qui jouent le jeu du JCP vont investir des sommes importantes pour concevoir de nouvelles versions de leur serveur d’application Java EE pour supporter cette nouvelle version. Je serais surpris qu’Oracle ne soit pas en train de chercher un axe juridique pour attaque VMware et Spring sur des histoires de noms ou de brevets autour de leurs serveur d’application par exemple. L’univers des avocats étant tortueux, il n’est pas impossible qu’il trouve quelque chose.
Autre cible toute désignée : Google et GAE. Cette plate-forme géniale reste quand même une version propriétaire de Java. Dès qu’une application est développée sur GAE elles devient prisonnière de la plate-forme (impossible de la faire tourner ailleurs) et ça c’est contraire à l’esprit de Java. Je ne serait pas surpris qu’Oracle organise une descente dans le Squat de Google pour récupérer quelques dollars au passage…
Les issues possibles
L’arrivée d’Oracle aux manettes de Java, c’est un peu se retrouver sur un grand 8 après avoir écumé tous les carrousels de la foire. Ca secoue beaucoup et dans toutes les directions. La communauté Java voit globalement d’un mauvais oeil toute cette agitation. Je ne suis pas non plus embalé par tout ce qui se passe mais j’aurais tendance à penser que c’est mieux que l’immobilisme auquel nous avait habitué Sun : ça fait avancer les choses.
Soit Java sortira renforcé, soit l’action d’Oracle précipitera la chute de la plateforme et là nous serons au moins qu’il faut passer à autre chose.
Ces dernières semaines l’idée du Fork de Java flotte dans la communauté. Je pense que c’est vraiment de l’ordre du fantasme surtout quand on voit qu’un projet comme Harmony lancé il y a 5 ans n’est pas encore totalement achevé malgré l’implication d’un poids lourd comme IBM.
L’issue que je vois, est plus pragmatique : quand Oracle aura fini de relever les compteurs et aura un peu mis au pas la cacophonie autour de Java, la plateforme repartira sur des bases plus claires et plus rentables. Reste à savoir si nous serons en accord avec cette nouvelle politique.
