vendredi 24 juin 2011

Veille technologique semaines ... dernières.

Pour le bulletin de cette semaine, je vous propose les sujets suivants :
  • sortie de la version 3.7 de l'outil eclipse Indigo : 62 projets, 46 millions de ligne de code, 408 développeurs, 49 organisations qui contribues.
  • L'avenir de Java : comment Oracle va gérer cet écosystème.
  • Sonar : la qualimétrie du logiciel pour tous.
  • Un livre sur le CMMI avec un chapitre pour le niveau 2.
  • Un article d'IBM au sujet du développement d'application Java temps réel : temps de réponse garantie.
  • Les revues de code et les résultats.
  • Le HTML5 et Microsoft : changement de stratégie ?
  • Les optimisations de la machine virtuelle Java.
  • Le garbage collector du JDK 7 : Garbage First
  • Une demande d'évolution du langage Java : les énumérés devrait être extensible
  • La méthode clone() en Java : comment faire ?  A automatiser dans un outil UML.
Bonne lecture.


Eclipse 3.7 (Indigo) now available
Right on schedule, The Eclipse Foundation has released Eclipse 3.7 (Indigo). Actually, Indigo is a simultaneous release of dozens of projects including the Eclipse Platform, Java development tools, source control tools, GUI designers, and more. This is the eighth successive year in which the Eclipse community has shipped a coordinated release on schedule.


Eclipse Indigo Released
The Eclipse Foundation has announced the release of Eclipse Indigo, a combination of 62 projects with a combined total of 46 million lines of code between them. Eclipse has followed an annual release train of the last week or two of June since Callisto in 2006, although the Eclipse platform has been released annually since 2001.

The simultaneous release allows all projects to standardise on a particular set of dependencies; useful when later projects depend on earlier ones (such as JDT depending on Platform, or Mylyn on EMF). Prior to Callisto, projects would often have specific dependency sets which needed to be satisfied causing problems for wide adoption of certain projects. Since the annual combined release train, stability and interoperability between projects has improved dramatically.


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 . 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.


Sonar, l'outil qui manquait à l'usine de développement .NET
Sonar (www.sonarsource.org) est un outil de reporting sur la qualité des projets informatique. Bien qu'à l'origine fait pour le Java, la communauté Open Source a permis l'intégration de Sonar avec d'autre langages : cobol, flex, php, c++ et maintenant .NET.
L'objet de cet article est de vous montrer ce que peut apporter Sonar pour un projet informatique et montrer quelle est sa place dans l'univers .NET.


Interview and Book Excerpt: CMMI for Development
The CMMI for Development (CMMI-DEV) framework, developed at the Software Engineering Institute (SEI), can be used to improve product quality and project and organizational performance.
InfoQ spoke with Mike Konrad, co-author of the book published on the CMMI-DEV framework. We are also making two excerpts from the book ("Applying Principles of Empiricism" from Chapter 3 and "Switching Tracks: Finding the Right Way to Get to Maturity Level 2" from Chapter 6) available for our readers.


Develop with real-time Java
Create applications with predictable response times
1. Why real-time Java?
Runtime processes (garbage collection, class loading, Just-in-time compilation, and thread scheduling) in conventional Java virtual machines (JVMs) make them incapable of running applications with real-time behavior. Real-time extensions to Java technology—based on the Real-time Specification for Java (RTSJ)—enable JVMs with real-time features. You can meet the hard or soft real-time constraints your applications require by leveraging the traditional benefits of the Java language—such as interoperability and safety—and combining them with features that the real-time Java extensions enable. Learn how.


Not doing Code Reviews? What's your excuse?
All of us have known for a long time that code reviews find defects, and that reviews are cheaper and can be more effective than most kinds of testing. In Code Complete, Steve McConnell builds an overwhelming case for code reviews: disciplined code inspections can find between 45%-70% of all defects in code, while even fast, informal reviews can find 20%-30%. Studies at IBM, HP, Microsoft and other places show that it is several times cheaper to find bugs in code reviews than through testing. And evidence keeps coming in to support that code reviews work.


La révolution HTML 5 chez Microsoft va laisser des traces
Il ne se passe pas un jour sans qu'on ne parle d'un fait lié à HTML 5, que ce soit pour encenser ces vertus multiplateformes, enterrer ses principaux concurrents ou annoncer une n-nième spécification. Le dernier en date et non des moindres est la présentation officielle de Windows 8 par Microsoft. Difficile de rester insensible à ce mouvement de fond, que dis-je ce tsunami technologique qui secoue en ce moment la firme de Redmond. Quelle histoire rocambolesque que celle de la stratégie RIA d'un éditeur qui ne sait clairement plus vers quel saint se vouer. Pour bien comprendre l'ampleur du désastre, faisons un petit retour en arrière.


Java HotSpot™ Virtual Machine Performance Enhancements
Compressed Oops
Zero-Based Compressed Ordinary Object Pointers
Escape Analysis
NUMA Collector Enhancements
NUMA Performance Metrics


Garbage-First Collector
What is the Garbage-First Collector?


Java Should Have Extended Enums!
At Devoxx09, Joe Darcy presented the status and future of the Coin project, and how changes to the language are selected and implemented (or vice versa). During his talk, he showed the cost classification of a language change: trivial, small, medium, big, or huge, and emphasized the fact that each change is also a benefit (hard to measure a priori) that can be estimated as big, medium, or small.


La Méthode Clone()
Comment rédiger la méthode clone() ? Quand utiliser Cloneable ? Ce document répond à ces questions.
Il est souvent nécessaire de dupliquer une instance. Cela permet de gérer correctement les exceptions et les agrégations. Nous désirons proposer une méthode public clone() retournant une copie d'une instance.