new Blog( perso );

Exemple concret : le nouveau Garbage collector "G1", dont les performances sont encourageantes pour ce qui en a déjà été présenté (même si on présente rarement de mauvais résultats). Un petit tour par la release-note :

Vous avez bien lu, pour utiliser G1 en production vous devrez passer par le porte monaie et souscrire un contrat de support "business program".

Donc SUN a d'un côté ouvert le JDK en GPL (ce qui lui permet à la fois d'être libre sans risquer de se le faire piquer) et de l'autre finance des développements plus avancés selon un contrat de support classique. Un modèle de développement opensource assez classique en fin de compte, la version "de base", libre, servant à faire adopter la plateforme tandis que la version "business" est orientée support et fonctionnalités avancées.

D'autres éditeurs ayant choisis ce modèle redonnent leur code "avancé" à la version libre une fois que son développement a été amorti. Il semble que ce soit l'idée de SUN pour G1, dont le développement et la mise au point sur des applications stratégiques nécessite des ressources significatives. 

Reste à savoir ce que cela va donner à l'avenir, avec bien sûr la question clé de la position d'Oracle sur le sujet, qui n'a pas montré jusqu'ici un engagement fort dans l'opensource. G1 sera t-il réellement "libéré" et intégré à OpenJDK ou faudra t-il attendre un développement alternatif qui s'en inspire ? Qu'en sera t-il des autres évolutions significatives du JDK de sun ?

La polémique autour du rachat de SUN n'est pas prète de s'épuiser ;)

Les choses évoluent dans le bon sens : Jason a reconnu que le développement de Maven 3 nécessite un gros investissement personnel ne serait-ce que pour se tenir au courant. Il ne compte pas renoncer à son rôle de développeur pour celui de responsable communication en fournissant à la communauté un joli résumé du 'où c'est qu'on en est', mais ne veut pas pour autant se couper de la base communautaire du projet.

Dernier rebondissement, l'organisation de conférences téléphoniques hebdomadaires permettant de discuter "live" de l'état et de l'avenir du projet, une idée reprise du fonctionnement de la fondation Eclipse. Enregistrées pour ceux qui ne sont pas disponibles à l'heure dite (17h pour la france), ou dont l'anglais est trop approximatif pour suivre une discussion sans décrocher, ces débats seront consultables dans les jours qui suivent et pourront être poursuivis par des questions plus précises via la liste de dev.

Ce fonctionnement devrait permettre à plus de monde de mettre un pied dans Maven 3, sans pour autant alourdir le processus de développement. Documenter chaque choix technique mis en oeuvre serait en effet un travail titanesque.

Bonne nouvelle donc. Après la renaissance de Maven 2.x (une 2.2 est en cours de finalisation), Maven 3 va devenir plus visible pour la communauté. Les devs de Maven 3 se focalisent sur la compatibilité avec l'existant maven 2, via une large batterie de tests d'intégration. Un travail important auquel la communauté peut contribuer en proposant de nouveaux tests IT sur des cas spécifiques. Les résultats sont semble t-il encourageants, aussi on peut espérer avec un Maven3-SNAPSHOT fonctionnel, même si la stabilisation définitive va prendre du temps.

En parallèle, des membres francophones de la communauté se sont portés volontaires pour traduire le definitive guide en français, travail à long terme vu le pavé que constitue ce bouquin, mais qui va apporter à Maven une documentation plus accessible - en complément, bien sûr, de mon bouquin ;)

Hibernate tente de détecter la présence de Hibernate-validator, et si c'est le cas active ses fonctions optionnelles. JBoss a eu la bonne idée de nous coller d'office un Hibernate dans son serveur d'appli, comme si nous n'étions pas capable de choisir nous même nos outils. Le Hibernate-validator détécté au runtime est celui de JBoss et évidement incompatible avec la version d'Hibernate que j'utilise.

Autrement dit, le "conteneur" me rend là un magnifique service en m'obligeant à intégrer une version plus récente d'Hibernate-validator que je n'utilise pas. Je vous passe les problèmes de parser et d'API XML et les diverses Error associées. Même si après tout c'est ce qui me fait gagner ma croute vu que peu de gens comprennent de quoi il s'agit, je me passerais bien de perdre des heures sur ce genre de sotises.

Question 1 : pourquoi le serveur d'appli devrait-il nous fournir des frameworks, nous privant ainsi du choix d'une version précise ? Il est difficile de faire une mise à jour de serveur sur des machines mutualisées, je me suis coltiné un Websphère 5.0 pendant des années pour cette raison. 

Question 2 : Pourquoi le classloader isolé (parent-last) n'est-il pas le mode de fonctionnement par défaut ? Tous ceux qui ont galérés avec commons-logging savent de quoi je parle

Question plus fine : pourquoi le serveur d'appli héberge t-il l'application et pas l'inverse ?

Dans la majorité de mes applis, en dehors de l'API servelt et d'une DataSource le serveur d'appli ne sert pas à grand chose (je suppose que ces fonctions d'exploitation sont mise à profit par mon client). Pour la DataSource, un bon commons-dbcp fait très bien l'affaire et économise les raffinements de la configuration des liens JNDI. Pour l'API servelt, je préférerais autant démarer au sein de mon application un service d'écoute HTTP, un Jetty embedded ou équivalent, quitte à ce que la classe associée soit configurable.

Spring DM Server de ce point de vue me décoit un peu car il ne remet pas en cause cette structuration des applications dans un conteneur (et je reste perplexe sur l'intérêt d'OSGi). J'attendrais du serveur d'application idéal de fournir des services à la carte, mais surtout rien de plus. En gros une JVM++, pas une de ces usines à gaz auxquelles JEE nous a habitués.