dimanche 9 novembre 2014

Glassfish : un an après, Glassfish est-il vraiment mort ?

Il y a 1 an  Oracle décidait d'abandonner le produit commercial Oracle Glassfish Server et incitait ses clients à migrer sur son serveur WebLogic.

Aussitôt, un concert de voix plus ou moins bien intentionnées avaient posté ça et là des articles alarmistes sur le nième coup de canif porté à Java par Oracle et sur l'urgence d'abandonner Glassfish.

Quel est le problème ?



Oracle est suspect depuis le début de son aventure Java : on soupçonne cette entreprise d'avoir une stratégie cachée concernant Java.


Le but inavoué serait donc de tuer Java après avoir dépensé des milliards de dollars pour acquérir cette technologie via le rachat de SUN.

Oracle serait également aux yeux de ces détracteurs un piètre défenseur de l'esprit Open Source qui anime la communauté Java.

Il y aurait donc un complot Oracle visant à détruire Java. 

Personnellement, je n'ai pas encore compris quel était l'intérêt économique d'une opération de ce type et personne n'a été capable de me l'expliquer mais les théories du complot se moquent bien de la logique.

Qu'Oracle soit fort mal à l'aise avec les pratiques d'un écosystème basé sur l'Open Source et qu'il y ait eu des maladresses est une autre histoire.

Oracle est un des plus grands éditeur commercial de logiciels et de solutions d'entreprise : la défense agressive de ses intérêts fait partie de son ADN dans un environnement concurrentiel fort, comme les autres éditeurs d'ailleurs.

Il est clair que cette agressivité passe mal auprès de la communauté Java qui était habituée à une approche plus douce de la part de SUN.


L'aventure Glassfish, une preuve de plus du complot Oracle  ? 


La décision d'Oracle concerne la version commerciale de Glassfish qui propose des extensions commerciales à la version Open Source Gratuite.

Glassfish reste l'implémentation de référence de JEE ce qui par définition même implique la gratuité et l'ouverture des sources de ce serveur : toute implémentation de référence doit respecter cette règle.

Par ailleurs, tout éditeur de logiciel commercial décide comme bon lui semble de la vie de ses produits. 

C'est un droit inaliénable  pour tous les éditeurs du monde qui impacte tous les ans des millions d'utilisateur : Microsoft arrête le support de ceci ou cela et pousse ses clients sur X ou Y, SAP arrête le support de .., .... 

Google ne se prive pas pour arrêter des produits par ailleurs fort utilisés ou appréciés par exemple, lors des fameux nettoyages de printemps.

Dépendre d'un éditeur et d'un produit commercial est un risque quelque soit le contexte, Oracle ou pas.

Les gens l'oublient trop souvent ...

Ce mouvement d'Oracle est donc typique de l'attitude d'un éditeur qui défends ses intérêts. D'autre part, il indique à ses clients que l'équivalent d'OGS est le serveur WebLogic. 

Les clients qui voulaient donc un serveur JEE avec support ont une solution qui n'est pas forcément plus onéreuse mais effectivement ce serveur n'est plus la version commerciale de Glassfish.

Oracle n'a cependant pas abandonné Glassfish Open Source.

Glassfish Open Source n'est pas prêt pour la production car c'est une implémentation de référence ?


Des bloggeurs ont avancé cet argument qui est assez étonnant.

La plupart des serveurs JEE sont d'abord des intégrateurs de composants développés par les uns et les autres. 

Ces composants sont plus la plupart des implémentations de référence des différentes normes JEE.

L'intégration de ces composants forme le serveur JEE qui se voit aussi doté de composants non présents dans la norme JEE : administration, clustering, ...

Regardons de plus près quelques exemples de partage de composants entre serveur JEE :



Glassfish Wildfly
JDK Open JDK Open JDK
CDI Weld Weld
JSF Mojarra Mojarra
JPA EclipseLink Hibernate
JAX-RS Jersey RestEasy
JAX-WS Metro CXF
JSONP jsonp jsonp
Websocket Tyrus Undertow
Batch Spring Jberet
EL Glassfish EL Glassfish EL


Développer un serveur JEE certifié est tout simplement une tâche titanesque; aujourd'hui aucun éditeur fusse-t-il commercial, n'a développé un serveur JEE 7 sans utiliser des composants tiers.

Or, Spring Batch ou bien Mojarra sont des composants de type RI utilisés par des serveurs dit de production : il n'y a pas de distribution dégradée de Mojarra, Spring Batch, Glassfish EL ou Weld.

Enfin, les documentations des différents serveurs montrent qu'il est possible de substituer des implémentations par d'autres : EclipseLink par Hibernate et vice versa par exemple. 

Cette capacité est liée à la norme JEE qui définit une séparation claire entre l'API et l'implémentation.

Les éditeurs de serveur JEE se comportent comme les grands de l'industrie automobile, à la fois intégrateur et innovateur.

Glassfish Open Source n'est pas prêt pour la production car les fonctions avancées de production vont disparaître ?


En effet, ces fonctions avancées ne font partie de JEE : l'éditeur les proposait cependant avec Glassfish 3 parce que la version Open Source et Commerciale partageaient un tronc commun assez large.

A partir du moment où la version commerciale meurt pourquoi Oracle se fatiguerait à fournir ces fonctions dans la version Open Source ?

Depuis de nombreuses années, Tomcat est utilisé sans proposer de véritables fonctions avancées dans ce domaine et sans que cela nuise à sa renommée ou à sa popularité.

Nombre de ces fonctionnalités comme le clustering ou le load balancing peuvent être assurés par des composants tiers comme Nginx ou Apache Httpd, voire ne sont de toutes façons pas très recommandées : la réplication de session est par exemple loin d'être l'état de l'art des applications webs qui recommande l'approche stateless avec REST pour permettre une scalabilité forte notamment dans le cadre d'un déploiement dans un cloud intelligent.

En 2014, Glassfish 4 propose toujours ces fonctionnalités malgré la crainte des commentateurs de l'époque.

Conclusion

Lors de l'annonce de l'abandon du support commercial, une vague de réaction négative a pris le dessus sur la raison.

Oracle de part son attitude parfois agressive envers ses compétiteurs Open Source a le don de crisper la communauté Java et certaines de ses grandes voix.

Il n'empêche que depuis un an, Glassfish continue son bonhomme de chemin. 

Java n'a jamais autant avancé avec Java 8 et des ambitions importantes sont affichés pour la suite.

Même James GOSLING, l'inventeur de Java qui est parti  en claquant la porte, a adouci son jugement

Dans tous les cas, il faut toujours limiter les adhérences aux implémentations et essayer de ne dépendre que des APIs JEE dans vos applications. 

Quant aux fonctions avancées non JEE, limitez leurs usages au strict nécessaire voire diminuez le risque en utilisant d'autres produits qui semblent moins risqués.

JEE est d'ailleurs un socle assez unique quand on le compare à d'autres écosystèmes qui n'offrent pas ce niveau de normalisation ce qui rend la dépendance à un produit inévitable et donc très risquée sur le moyen/long terme (les technologies webs clientes sont assez spectaculaires à cet égard).