Veille technologique semaine 9

Pour le bulletin de cette semaine, je vous propose les sujets suivants :

• les Microsoft techdays
• HTML 5 et ses nouveautés
• La conférence OSGi à Londres,
• La commutation de contexte chez les humains : il faut la minimiser car non optimisée.
• Les architectes logiciel ?
• Les couches et management
• La fusion de HotSpot et JRockit
• La modularité du JDK 7
• Un pattern pour les constantes initialisées dynamiquement en Java.
• Un Quiz Java

Bonne lecture.


Microsoft Techdays 2010 (2/3)
Les Techdays sont l'occasion pour Microsoft de présenter chaque année à ses utilisateurs, du plus geek au plus boss, sa gamme de produits, d'outils sous forme de présentations, d'ateliers ou de retour d'expérience. Difficile de couvrir complètement cet événement tant l'offre de sessions est pléthorique, nous vous proposons donc, à travers une série de posts (voir le premier [1]), sur les sessions que nous avions choisi et de partager avec vous notre ressenti. Ce deuxième post est orienté nouveautés serveurs, cloud … et un petit bonus.


HTML5 – Les nouveaux éléments
Comme évoqué dans une précédente revue de presse, voici le premier article de ma série sur HTML5. Plutôt que de faire du comptage de points entre Apple et Adobe, j'ai décidé de commencer par faire un tour d'horizon des nouveautés proposées par cette nouvelle spécification du W3C. Dans ce premier article, je vous propose donc de faire un voyage à la découverte des nouveautés du côté de HTML. ; pour connaître les nouvelles balises, et les nouveaux attributs que nous pouvons déjà ou pourrons bientôt utiliser dans nos navigateurs. Du layout au canvas en passant par les WebForms, le son et la vidéo, tout tout tout, je vous dirai tout sur HTML5. Commençons donc par le commencement: HTML5 qu'est-ce que c'est ?


OSGi DevCon London
Last week saw the first OSGi DevCon London, held in conjunction with JAX London in Hammersmith's Novotel. The keynote by Kirk Knoernschild available beforehand as a preview, packed the room to standing room only.
Kirk's presentation (slides) did not focus on OSGi directly, but rather on complexity of software and what projections the future holds. Analysis of the past growth of source code suggests that the number of lines of code ever written doubles every seven years; to put it another way, by 2017, the world will have as much new code again as ever existed up until 2010.


Human Task Switches Considered Harmful
In fact, the real lesson from all this is that you should never let people work on more than one thing at once. Make sure they know what it is. Good managers see their responsibility as removing obstacles so that people can focus on one thing and really get it done.


Are You a Software Architect?
The line between software development and software architecture is a tricky one. Some people will tell you that it doesn't exist and that architecture is simply an extension of the design process undertaken by developers. Others will make out it's a massive gaping chasm that can only be crossed by lofty developers who believe you must always abstract your abstractions and not get bogged down by those pesky implementation details. As always, there's a pragmatic balance somewhere in the middle, but it does raise the interesting question of how you move from one to the other.


Layers of Management == Layers of Veto
In an organization with more than one layer of management, the default answer must be "no". Folks get needlessly frustrated by this. But it's a logical consequence of multiple layers of management. Consider that direction must come down from above. If you're suggesting something up to your manager (or in your role as an outsider) the response must be "no". What you're suggesting is not the direction that came from above.


La fusion JRockIt / Hotspot pas pour demain

Nous en parlions il y a quelques semaines, Oracle envisage de ne proposer à l'avenir qu'une seule JVM, qui tirerait le meilleur des deux que la firme s'est offert (JRockit via BEA, et Hotpsot via Sun). Dans un récent webcast (via InfoQ), Mark Reinhold s'est exprimé sur le sujet. Cette fusion n'est pas pour tout de suite : trop de clients utilisent les fonctionnalités spécifiques à l'une ou l'autre des JVMs en production, et il serait risqué de les forcer à migrer vers une version fusionnée bancale. Ce dernier se dit jaloux de certaines fonctionnalités de JRockIt et donc particulièrement excité d'avoir l'occasion de l'étudier en profondeur. Cependant, ce qui transparait dans son discours (et peut être via nos diverses expérience), c'est que la JVM de Sun est en avance sur celle de BEA. La prochaine version fusionnée devrait donc tendre plus vers Hotspot que vers JRockit. En résumé rapide, cette future VM Oracle devrait avoir les fonctionnalités runtime de Hotspot, et le garbage collector et la robustesse de JRockit. Finalement, à part l'ébauche d'une timeline, nous ne sommes pas beaucoup plus avancés.
Coté nouveautés du JDK 7, Mark Reinhold se dit aussi particulièrement excité par l'intégration du projet Coin (au contraire de la grande majorité des consultants Xebia, qui trouvent que la plupart de ces évolutions syntaxiques confinent au gadget).
Il reparle aussi des closures, principalement sous l'angle des raisons de la polémique, mais personne ne semble réellement savoir comment elles seront implémentées dans le JDK 7 (voir ci-dessous pour l'avancement du projet Lambda).
Dernière annonce, pour ceux qui comme lui sont impatients de voir une JVM enfin modulaire (aka Jigsaw, prévu dans le JDK 7, voir ci-dessous), ils devraient en avoir un aperçu mi-mars, avec la release 88 de l'OpenJDK.

Certains noteront avec un certain amusement (ou une certaine nostalgie) quelques ratés : "We, at Sun..."

Jigsaw, les modules du pauvre ?

Adam Bien est l'un des Java champions les plus visibles et les plus lus d'internet. Il a publié cette semaine un petit article au titre accrocheur : « Jigsaw / JDK 1.7 sera une solution qui permettra de répondre à 80% des besoins de modularité ». Vous avez probablement suivi les différents épisodes et rebondissements de la modularité dans le JDK 7. C'est peut-être l'occasion de faire le point sur ce que propose Jigsaw.

Le projet Jigsaw proposera une implémentation permettant la mise en place d'un système de modules bas niveau pour vos projets. Il sera également utilisé en interne pour découper le JDK Oracle/Sun lui-même.

• Jigsaw vous permettra de choisir tout ou partie du JDK tout en restant 100% rétro-compatible, d'améliorer les temps de démarrage de la JVM et son utilisation mémoire.
• Jigsaw pourra être utilisé directement sur vos projets si vous disposez d'une JVM reposant sur ce système. Jigsaw sera chargé avant rt.jar et sera donc disponible à quiconque désirant l'utiliser. Ce projet étant open source, il sera également possible de réutiliser celui-ci dans d'autres contextes.
• Jigsaw vous permettra de rendre vos applications modulaires progressivement. Nul besoin de migrer vos applications dans leur ensemble pour tirer parti des bénéfices de la modularité. Un même package peut être éclaté dans plusieurs modules.
• À l'instar d'OSGi, Jigsaw n'est pas un moyen de recharger vos modules à chaud. Vos modules sont chargés statiquementau démarrage de vos applications.
• Tous vos modules sont chargés dans un même classloader, cela permet de simplifier grandement son utilisation. Du même coup, il vous sera probablement possible de 'tricher' en chargeant, au runtime, des classes d'un module sans que vous en ayez réellement le droit.

Si vous confondiez modularité du JDK avec OSGi, cette liste vous a certainement ouvert les yeux : Jigsaw vous propose une solution beaucoup moins fournie qu'OSGi.

Dans les faits, ce projet a été créé, avant tout, pour casser notre bon vieux JDK monolithique. Bon nombre de polémiques ont été faites sur ce choix. Pourquoi se contenter d'aborder 80% des problématiques de la modularisation avec une nouvelle solution alors qu'OSGi en aborderait 90% ? La simplicité et la souplesse d'utilisation ont été préférées à une solution décrite comme lourde (nécessitant beaucoup de glue), vieillissante (datant de 1998) et difficile à maîtriser. Ce choix a été sans conteste difficile à effectuer, il s'est ailleurs attiré les foudres des défenseurs d'OSGi, mais reste complètement défendable


Declaring Final Variables Elegantly Using The Assigner Design Pattern
A final variable is used to define a constant value and reference, and can only be defined once. In most cases, declaring a final variable is just a matter of assigning to a primitive value or an object reference directly. However, in some cases, declaring a final class/instance variable may be more involving especially it gets assigned from a method that throws an Exception (eg API for database access, web access), or it may involve multiple statements.


Java Quiz #33
La classe ci-dessous part d'une bonne intention, mais où est le problème ?