Revue de Presse Xebia

La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.

Agilité

• La communauté agile européenne se fédère

Le coin de la technique

• Un livre libre sur l’Architecture logicielle
• Lumière sur le futur Grails 1.4 : Tests unitaires

Evénements de notre communauté en France et à l’étranger

• L’avenir de Java se joue maintenant

Agilité

La communauté agile européenne se fédère

Il était temps que l’Europe s’émancipe un peu de l’énorme influence de son voisin américain en matière d’agilité. C’est sous l’impulsion de Jurgen Appelo, dont le blog est l’une des toutes premières sources de lecture de la communauté agile mondiale, que s’est créé un groupe Agile Lean Europe en février dernier. D’abord simple rassemblement d’agilistes sur LinkedIn, le groupe s’est depuis diversifié dans ses activités et dans ses échanges à une vitesse impressionnante. Les membres ne comptent pas leurs efforts pour fédérer les forces vives de l’agilité aux quatre coins de l’Europe.

Le premier rassemblement physique de ce réseau virtuel a eu lieu mi-mai lors de la conférence XP2011 en Espagne, avec une poignée de représentants de divers pays Européens, et cette rencontre a accéléré plus encore la débauche d’énergie pour créer une véritable culture européenne de l’agilité. Parmi les initiatives les plus marquantes on peut noter les deux suivantes:

• Les « bathtub conferences »: conférences virtuelles planifiées en soirée où chacun peut participer sans contrainte professionnelle ou résidentielle (et donc depuis sa baignoire si l’envie lui prend). La deuxième se tiendra le 30 juin de 21h à 23h (inscription ici), et vous pouvez retrouver les videocast de la première sur YouTube. On y parle notamment des tests automatisés chez eBay (comme quoi l’influence de notre voisin américain est encore bien présente :-) ).

• ALE2011: la première « unconference » qui se veut pleinement européenne, prévue à Berlin en Septembre, les pré-inscriptions sont ouvertes. Attention, il y a un quota de 10 représentants par pays (on aime bien les quotas en Europe).

En conclusion, et si vous ne l’avez pas déjà fait, rejoignez le groupe ALE sur LinkedIn. See you there!

Le coin de la technique

Un livre libre sur l’Architecture logicielle

C’est par un lien donné par Emmanuel Lecharny sur le Google Group des Castcodeurs que nous l’avons découvert: un livre intitulé « The Architecture of Open Source Applications » vient de sortir. Comme nous l’apprend la FAQ, tout est parti de Greg Wilson, enseignant en Architecture logicielle au Canada, qui était frustré face aux livres existant sur le sujet. Il a donc été le chef d’orchestre pour rassembler divers écrits de personnes directement impliquées dans les projets Open Source qui on décrit leurs architectures respectives mais aussi quelques anecdotes sur l’historique des projets.
Parmi les projets, on retrouve des projets Java, mais pas seulement. Notons par exemple Eclipse, Hadoop, Selenium Webdriver mais aussi LLVM ou le système de packaging de Python. C’est donc un beau cadeau que ce livre et nous aurons tous beaucoup à retirer de ce tour dans les entrailles de tous ces projets.
Le livre est sous licence Creative Commons Attribution (CC BY 3.0) consultable en ligne, mais aussi téléchargeable en PDF ou disponible sous forme papier.

Lumière sur le futur Grails 1.4 : Tests unitaires

Sur le blog de SpringSource, Peter Ledbrook inaugure une série de billets sur les améliorations apportées par Grails 1.4. Le projet en est actuellement au stade de la première Milestone, et il semble que SpringSource tente d’intéresser un maximum de développeurs à la prochaine version de Grails. Le premier volet concerne les améliorations apportées aux tests unitaires. Parmi celles-ci on peut noter :

• Fin de l’utilisation de l’héritage pour les classes de tests.
• Implémentation en mémoire de GORM, pour un meilleur mocking du domaine.
• Facilitation des tests de contrôleurs renvoyant du JSON ou du XML.

Pour le détail, voir le billet chez SpringSource.

Evénements de notre communauté en France et à l’étranger

L’avenir de Java se joue maintenant

Cela ne vous a sans doute pas échappé: cette semaine fut particulièrement riche en évènements liés à l’avenir du langage Java et aux instances qui gouvernent son évolution. Voici un tour d’horizon des moments les plus marquants.

Coup de tampon sur Java SE 7

Tout commence par le vote public du JCP (Java Community Process) au sujet de la JSR 336. Les enjeux étaient de taille, vu qu’il s’agit ni plus ni moins de la JSR Umbrella qui chapeaute la version 7 de Java SE.

Commençons par les bonnes nouvelles: la JSR a été approuvée! L’évènement a d’ailleurs été abondamment commenté, par exemple par nos confrères de Développez.com, de H Online ainsi que par Nicolas Martignole, et les résultats sont disponibles ici.

Java SE 7 est donc sur les rails, et c’est plutôt rassurant quand on pense que les spécifications finales et l’implémentation de référence sont attendues pour le 28 juillet prochain. Mais lorsqu’on se penche sur les détails du vote, le tableau est hélas nettement moins rose.

Certes VMWare, la Fondation Eclipse, Intel, SAP, HP, Ericsson et bien entendu Oracle lui-même ont voté pour sans réserves. Mais de nombreux membres — IBM, Red Hat, Goldman Sachs, Fujitsu ainsi que les JUGs brésilien (SouJava) et londonien (London Java Community) — ont émis de sérieuses réserves et ont tous souligné que leur approbation était due exclusivement aux « mérites techniques » de la JSR.

Quant aux grincheux, nous retrouvons Werner Keil qui s’est abstenu, et surtout Google qui — sans surprise — a voté contre.

Mais que reprochent-ils à cette JSR et, par-delà, à la firme de Larry Ellison?

Il s’agit tout d’abord du vieux problème des licences du TCK, dont la revue de presse s’est fait l’écho ici et là. Sun, puis ensuite Oracle, auraient placé des restrictions d’usage (Field of Use restrictions) restreignant les plateformes sur lesquelles le langage Java peut tourner et être certifié — nous y reviendrons.

La principale victime de cet état de faits est aujourd’hui Google et l’utilisation qu’il fait du projet Apache Harmony dans son système d’exploitation Android. En plein procès contre Oracle à ce sujet, Google a tenu à manifester son mécontentement par un vote négatif assorti d’un commentaire acerbe: « les licences du TCK ne doivent pas être utilisées pour restreindre ou créer une discrimination à l’encontre d’implémentations compatibles des spécifications Java en incluant des restrictions d’usage sur les implémentations testées. De telles licences ne sont pas conformes aux exigences du JSPA, et violent les attentes de la communauté Java quant à la libre implémentations des spécifications du JCP ». Pour rappel, le Java Specification Participation Agreement (JSPA) est le contrat même d’engagement des membres du JCP.

Un autre point vertement reproché à Oracle, notamment par les JUGs brésilien et londonien, concerne le manque de transparence du JCP lui-même. Oracle ferait preuve de mauvaise volonté à rendre publiques les archives de certains Expert Groups, en particulier celles du Project Coin. Cette attitude a manifestement compliqué la tâche des votants, à tel point que Werner Keil n’hésite pas à parler de « développements en cachette » — un comble pour un langage Open Source.

Y a-t-il un pilote dans l’avion?

Certains — Stephen Colebourne pour ne pas le nommer — n’hésitent pas à voir dans ce vote moins un satisfecit pour Java 7 qu’un arrêt de mort pour les ennemis d’Oracle, Apache Harmony en tête.

Dans son blog, Colebourne estime en effet que « le vote favorable ne fut possible que parce qu’Oracle a pris la décision de tuer Apache Harmony ». Il ne ménage d’ailleurs pas les membres actuels du JCP qu’il traite de « zombies » à la solde d’Oracle.

Or, malgré les protestations lors du vote, Oracle ne semble pas changer de cap. Quelle est sa stratégie actuelle?

Depuis le rachat de Sun, il semble que deux axes se dégagent dans la stratégie d’Oracle vis-à-vis de Java:

1. Empêcher les forks incontrôlés de Java pour des plateformes spécifiques (cf. Apache Harmony);
2. Conserver la sphère du développement mobile comme une source potentielle de revenus (cf. Google).

Toujours d’après Colebourne, c’est en effet à la lumière du procès Google vs. Oracle que l’on comprendrait mieux pourquoi Sun puis Oracle ont mis tant de soin à verrouiller la licence du TCK et se sont acharnés contre Apache Harmony. Le bouillant spec lead de la JSR  » Three Ten «  rappelle d’ailleurs qu’initialement Sun avait donné tous les gages nécessaires à la Fondation Apache; ce n’est que plus tard, sentant le danger imminent et notamment le risque de perdre la bataille sur le terrain du développement mobile, que Sun aurait retourné sa veste avec cette trouvaille juridique de génie que nous connaissons bien maintenant: la licence du TCK. Toujours selon Colbourne, cette stratégie est enfin sortie de l’ombre lors du comité exécutif du JCP du 6 octobre 2010: Oracle a alors exprimé publiquement ses craintes qu’Apache Harmony ne crée une menace de « fork » — menace que Google et son système Android, toujours d’après Oracle, auraient su habilement exploiter.

OpenJDK: libre certes, mais incontournable?

Chat échaudé craint l’eau froide: le différend avec Google est loin d’être terminé, mais Oracle semble d’ores et déjà en tirer les conséquences et veut désormais éviter de nouvelles menaces du type Google/Harmony en misant toutes ses cartes sur OpenJDK, projet auquel Oracle a habilement réussi à rallier IBM puis Apple.

Et c’est là qu’intervient le deuxième fait marquant de la semaine, signalé entre autres par nos confrères d’H Online: le 9 juin dernier, Henrik Ståhl, directeur des produits chez Oracle, a annoncé sur son blog que la nouvelle version de Java utilisera OpenJDK pour son implémentation de référence et non plus le JDK « maison » Sun/Oracle.

C’est à nouveau une affaire de licences: le JDK de Sun/Oracle est distribué sous la licence Binary Code (BCL). Cette licence est incompatible avec des implémentations Open Source (comme OpenJDK) en raison de composants comme le plugin Java, qui ne font pas partie du standard Java.

Oracle choisit donc de conférer à OpenJDK ses lettres de noblesse, en faisant de ce projet l’implémentation de référence de Java 7.

Concrètement, comment cela se passe?

D’après Ståhl, l’implémentation de référence sera disponible sous une double licence: BCL pour les implémenteurs commerciaux et GPL v2 avec exception de classpath pour les implémenteurs Open Source.

Autre changement notable: OpenJDK possède son propre TCK et la licence qui l’accompagne, baptisée OCTLA (OpenJDK Community TCK Licence Agreement), sera mise à jour afin de couvrir Java 7; le TCK sera alors théoriquement utilisable gratuitement par tout implémenteur Open Source.

Est-ce donc la fin du conflit autour du TCK?

Pas vraiment: les internautes, répondant à Ståhl, font observer que la licence OCTLA ne s’applique qu’à des implémentations « substantiellement dérivées » d’OpenJDK, et qui plus est, en cas de distribution par une tierce partie, impose qu’elles le soient sous licence GPL. La porte reste donc toujours close pour Apache Harmony… Ståhl enfonce d’ailleurs le clou: « rien de tout cela ne changera le refus d’Oracle d’accorder à […] Apache Harmony un accès au TCK à des fins de certification; en effet l’OCTLA ne donne accès libre au système de tests qu’aux implémentations dérivées […] d’OpenJDK ».

Pour les détracteurs d’Oracle, il s’agit d’une manoeuvre dont le but est de se dédouaner auprès de la communauté Open Source: oui, Oracle fait bien de l’Open Source! Ne l’a-t-il pas d’ailleurs rendu JRockit gratuit? Et désormais, voilà que vous pouvez créer librement votre propre implémentation de Java 7! Vraiment? Tant qu’on reste dans le giron OpenJDK, sûrement; mais au-delà, il n’y a probablement pas de salut. Ce que Colebourne résume par une savoureuse boutade: « Apache OpenJDK anyone? »

Les statuts de la Communauté OpenJDK font peau neuve

Troisième fait marquant de la semaine, mais qui découle du précédent: le 14 juin dernier s’est ouvert le vote pour la ratification des statuts de la Communauté OpenJDK. Ce vote prendra fin le 28 juin prochain.

Les statuts gouvernent le fonctionnement de la communauté OpenJDK: groupes, adhésion, procédures de contribution, gouvernance, etc.

L’électorat est constitué des contributeurs ayant « créé au moins 5 changements uniques et non-triviaux dans les dépôts Mercurial d’OpenJDK dans les deux années précédant le vote de ratification ». Or on s’aperçoit très vite que l’immense majorité des votants est affiliée à Oracle; même si quelques « dissidents » sont bien présents (Doug Lea notamment), certains ne manqueront sûrement pas de mettre en doute la légitimité d’un tel vote.

JCP++

Ce n’est pas à proprement parler une actualité, puisque cela date du 17 mai dernier, mais la nouvelle prend tout de même une autre dimension: le JCP va bientôt faire peau neuve.

Baptisé « JCP.next », ce JCP renouvelé sera défini par deux JSRs: 348 et 349 (cette dernière n’étant pas encore publiée).

La JSR 348 introduira des changements dans le fonctionnement du JCP lui-même. A la clé, quatre axes d’améliorations: transparence, participation, réactivité et gouvernance. Et la transparence, lorsqu’on se souvient du vote de la JSR 336, tombe à pic: entre autres, toutes les opérations des Expert Groups devront être menées dans des forums publics; les processus de recrutement de leurs membres seront également publics.

Mais il y a mieux: la JSR 349 quant à elle s’attaquera au JSPA. Or, on l’a vu, c’est là que le bât blessera très fort. Nos confrères d’IT World et de H Online notent à juste titre que le JSPA est au coeur du contentieux entre Apache et Sun/Oracle, la première accusant les seconds de ne pas la respecter.

Amender le JSPA, c’est donc jouer avec le feu; on ne peut qu’attendre avec impatience de voir comment Oracle s’y prendra.

Mais a-t-il seulement le choix?

Depuis quelques mois déjà le JCP est délaissé par des acteurs de première importance: la Fondation Apache d’abord, puis Doug Lea. Pour beaucoup, Stephen Colebourne et Doug Lea en tête, le JCP fait aujourd’hui figure d’institution sclérosée; ils veulent pour preuve des graphiques comme celui-ci, montrant le déclin dans le nombre de JSRs depuis quelques années. Pour d’autres, comme Nicolas Matignole, il est au mieux un moyen de faire face à l’adversité. Il n’est guère que le JUG londonien pour en vanter encore les mérites.

Après l’échec de sa stratégie concernant OpenOffice, Oracle semble cette fois-ci décidé à tirer les leçons de ses erreurs du passé: en adoptant Java SE 7, en mettant en avant OpendJDK, en réformant enfin le JCP, Oracle est peut-être enfin en train de donner des gages sérieux de pérennité au langage Java. Espérons seulement que la future JSR 349 nous donnera raison.