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

Actualité éditeurs / SSII

• Zeroturnaround ouvre la bêta de LiveRebel
• JDK 7, Developper Preview

SOA

• Integration sur le cloud

Le coin de la technique

• NetBeans 7 ne supporte plus Ruby : la communauté, si

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

• DevOps Day à Boston le 7 et 8 mars
• Nomination d’un « DSI Groupe » de l’état

Actualité éditeurs / SSII

Zeroturnaround ouvre la bêta de LiveRebel

ZeroTurnaround est la société auteur du fameux JRebel. Cette librairie, qui a déjà quelques années et rencontre un certain succès, permet de changer « à chaud » le code Java. Pendant le développement, on évite donc d’avoir à attendre un redéploiement et l’on peut tester rapidement ses modifications. Si le hot-reload (nommé Hotswap) existe de base en Java, il a des limitations que JRebel permet en grande partie de contourner.
Les petits malins de ZeroTurnaround continuent donc dans la même direction et nous sortent LiveRebel, équivalent de JRebel mais pour la production. Le bêta-test est donc ouvert à tous et cette version permet de contrôler jusqu’à trois serveurs. Comme JRebel, la version définitive sera payante.

Grâce à sa console tournant sur son propre serveur, LiveRebel, permet de:

• prendre en charge des nouvelles versions des applis (jar, ear, war) avec prise en charge:
  • des modifications de code (sauf remplacement d’interface et changement de superclasse)
  • des changements dans les ressources
• lister les différences entre 2 versions
• déployer une nouvelle version ou effectuer un rollback du code
• utiliser une API REST pour automatiser le contrôle des différentes actions

Pour plus de renseignements, la FAQ ainsi qu’un walkthrough sont à votre disposition.

La console avec les différences entre 2 déploiements:

Tout cela donne envie et on a tendance à se demander « mais pourquoi ça n’existait pas encore. ?! ». Néanmoins, on se gardera de se réjouir trop vite. Il serait très risqué de s’aventurer à tester du code en production en pensant que l’on pourra toujours le patcher à la volée. En effet le versionnement des données reste a prendre en compte: si un code bancal enregistre des données en base avec une erreur, il faudra y remédier en prévoyant:

• soit une verrue dans le code traitant ces cas particuliers
• soit un update correctif de la base

C’est donc certes faisable et LiveRebel reste une belle évolution, ne serait-ce que pour remédier rapidement aux bugs sans impact sur les données. Mais, et sans remettre en cause la qualité de la librairie, ce n’est pas l’arme absolue. Si l’on peut se permettre de faire abstraction de certaines problématiques sur un poste de développeur, il faudra bien se garder de toute précipitation sur « la prod’ ». Par ailleurs, et c’est étonnant, le forum du produit semble encore bien vide. Est-ce à dire que le produit est déjà parfait et sans bugs ?

JDK 7, Developper Preview

JDK 7 est à présent disponible pour les développeurs. Alors que le dernier milestone avait pour objectif de finaliser la liste des nouvelles fonctionnalités, cette version ( milestone 12 ) est relativement proche de la version finale et les développeurs sont invités à se l’approprier afin de faire la chasse aux bugs. La page de rapport de bug d’Oracle ou ses forums sont à votre disposition pour toutes remarques. Alors à vous de jouer en téléchargeant le dernier build ici.

SOA

Integration sur le cloud

Mulesoft a ouvert au public il y a quelques jours une version bêta de Mule iON, sa nouvelle plateforme d’intégration en tant que service (iPAAS). L’idée est de mettre à disposition un ESB qui fera le lien entre l’entreprise et ses différentes applications (voire services) sur le cloud.
Les principaux freins au déplacement des ESB vers les nuages restent les grandes inconnues du cloud : la sécurité, la répudiation, l’identification, la prise de contrôle… Mule iON tente de résoudre ces problématiques, en fournissant une gateway sécurisée, pour permettre à vos applications hébergées de communiquer avec vos clouds et les réseaux sociaux.
Il va de soit qu’une telle solution ne s’adresse qu’à de gros consommateurs de clouds (ceux qui ont plusieurs hébergeurs) ou des réseaux sociaux, avec d’importants besoins d’orchestration. Néanmoins, cela permet de s’abstraire de la gestion d’une infrastructure complexe dédiée à cette intégration de plus en plus difficile. Cette tendance, à surveiller, est peut être appelée à se développer fortement ces prochaines années, la multiplication des SaaS aidant.
MuleSoft ne propose pour l’instant pas d’élément de prix. La bêta de Mule iON se trouve ici.

Le coin de la technique

NetBeans 7 ne supporte plus Ruby : la communauté, si

Fin janvier, Oracle annonçait la fin du support Ruby dans l’IDE NetBeans. Cependant, la communauté des développeurs Ruby utilisant NetBeans ne s’y résout pas. Tom Enebo, l’un des committers principaux du projet JRuby, a annoncé dans un article sur DZone, le lancement du NetBeans Ruby Project. Cette initiative vise à assurer la continuité du support de Ruby au sein de l’IDE Oracle. Tom travaille à plein temps sur le développement de JRuby, sur lequel NetBeans a basé son support du langage jusqu’ici. Il a déjà annoncé que certains de ses camarades, piliers de JRuby, participeraient également au projet : Charles Nutter, Nick Sieger et Yoko Harada.

Tom Enebo a également été interviewé par DZone à ce sujet pour fournir plus de détails. L’appel est donc lancé à la communauté pour toutes les bonnes volontés qui souhaitent continuer à utiliser Ruby au sein de NetBeans. La structure du projet n’est pas encore complètement définie mais le projet existe. Merci à Tom et à tous les futurs contributeurs.

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

DevOps Day à Boston le 7 et 8 mars

DevOps, a pour objectif de réduire le mur d’incompréhensions entre les équipes de développement et les équipes d’exploitation.
Le premier évènement de l’année (DevOps Day) qui lui est consacré s’est tenu à Los Angeles la semaine dernière. L’une des présentations « DevOps : State Of the Union » est un recueil d’interview d’experts du secteur sur « où nous en sommes » et « où nous allons ». Ces experts parlent de leurs outils et de leurs idées pour faire de DevOps une réalité.
Le prochain évènement aura lieu à Boston, les 7 et 8 mars prochains. Le programme alterne des Open Spaces et des présentations formelles.
Un de ses organisateurs, Patrick Debois, en a d’ailleurs effectué fait hier soir au 3ème anniversaire du ParisJug. Il a rappelé que la priorité devait être toujours la satisfaction du client. Au travers de petites phrases comme « le développement n’a aucune valeur avant que ça fonctionne en production », il insiste pour que toutes les équipes travaillent ensemble. Pour ce faire, l’un des principaux moyens est de mieux s’outiller pour, à terme, obtenir des déploiements reproductibles.

Nomination d’un « DSI Groupe » de l’état

Le conseil des ministres vient de nommer un « DSI Groupe » de l’état : Jérôme Filippini. Il va être en charge de la coordination des différentes DSI de chaque administration et de l’optimisation de leur fonctionnement, notamment par la mutualisation de moyens. En tant que société de services, il est intéressant de savoir ce qui se cache derrière la mutualisation des moyens et quelles vont en en être les conséquences. Réduction des postes dans les DSI ? Création de cellules transverses ? De centre de compétences ? Mutualisation des infrastructures ? Nouvelles applications communes à toutes les administrations ? Affaire à suivre…

Actualité éditeurs / SSII

• Terracotta a faim d’Open Source : acquisition de Quartz
• JDK 7, JEE 6, et Maven 3.0 : les annonces de Devoxx

RIA

• GWT version 2.0 RC1

Le coin de la technique

• OWASP Security Top Ten, la cuvée 2010 est arrivée
• Que devient Spring Rich Client ?

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

• Devoxx 2009

Actualité éditeurs / SSII

Terracotta a faim d’Open Source : acquisition de Quartz

Terracotta a annoncé cette semaine l’acquisition de Quartz, le scheduler open source le plus connu est le mieux intégré du marché. Cette acquisition est l’exacte copie de celle opérée cet été avec Ehcache. Tout comme ehCache, Quartz est un projet open source, largement utilisé et bien intégré avec la plupart des solutions stars de leur secteur … et porté par un seul homme (James House). Cible idéale pour Terracotta ? Probablement. Mais il se pose toujours la question suivante : comment Terracotta compte t’il rentabiliser cette acquisition, quand on sait a quel point la monétisation d’un projet open source est difficile. Quoi qu’il arrive, d’ici la prochaine acquisition, Terracotta touche, par ce biais, une communauté de plus en plus large. Cela sera-t-il suffisant pour séduire un éventuel racheteur ?

D’autre part, comme le signale Alex Miller, Quartz c’est :

• Un nouveau site web.
• Un nouveau gestionnaire de sources.
• Un nouveau gestionnaire d’anomalies.
• Un nouveau forum.
• Mais toujours la même licence, Apache 2.

JDK 7, JEE 6, et Maven 3.0 : les annonces de Devoxx

La conférence Devoxx ayant eu lieu la semaine dernière a été l’occasion de plusieurs annonces importantes qui ont rapidement fait le tour de la blogosphère.

JDK 7 avec les closures, mais retardé à nouveau

C’est surement l’annonce qui à fait le plus de bruit. Elle s’est répandue comme une trainée de poudre tant elle était inattendue. Lors d’une présentation en apparence sans surprise sur les nouveautés du JDK 7, Mark Reinhold explique que le temps est venu pour Java de supporter les closures. Afin de permettre leur implémentation, la finalisation du JDK 7 est repoussée à septembre 2010. Trois nouveaux milestones sont donc ajoutés au calendrier initial avec une finalisation des fonctionnalités (features complete) prévue pour Juin 2010. Ce nouveau délai permet donc à l’équipe du JDK de travailler sereinement sur la finalisation de Jigsaw, d’implémenter les closures, et devrait vraisemblablement permettre également l’inclusion du multi-catch pour les exceptions.

En fait ce délai semble laisser la possibilité à de nombreuses autres fonctionnalités et spécifications qui avaient été mises de coté de prétendre de nouveau intégrer le JDK 7. On peut ainsi imaginer :

• JMX 2, qui avait été repoussé au JDK 8
• La JSR-310 (Date and Time API) qui avait connu des difficultés par manque de contributions et n’avait finalement pas été incluse à la liste finale des fonctionnalités du JDK 7
• La JSR-296 (Swing Application Framework) dont le retrait du JDK 7 avait été annoncé cet été
• Le support des propriétés

Questionné à Devoxx sur l’étendue des fonctionnalités pouvant être concernées par une potentielle inclusion, Mark Reinhold ne ferme la porte à aucune hypothèse. Il explique ainsi qu’il n’a pas eu l’occasion de voir de proposal pour les propriétés qui lui semblait satisfaisante jusqu’à présent mais n’exclue pas une telle possibilité d’ici la finalisation des fonctionnalités du JDK 7.

JEE 6 finalisé en décembre

Lors du keynote du premier jour des conférences, Roberto Chinnici (Spec lead JEE 6) a annoncé la finalisation de l’ensemble des spécifications JEE 6 ainsi que de l’implémentation de référence associée (Glassfish V3) pour le 10 décembre 2009.

Cette nouvelle intervient alors que JEE 6 a été très bien accueilli par le public à Devoxx comme il l’a été maintes fois répété dans le dernier épisode des Cast Codeurs.

Maven 3.0 finalisé en Janvier

Cette annonce est passée plus inaperçue parmi l’actualité de Sun. Pourtant Jason van Zyl, lors de sa présentation des nouveautés de Maven 3.0, a annoncé une finalisation de la nouvelle version de son outil de build pour la fin janvier 2010.

Cette nouvelle version apportera le support des builds multithreadés ainsi qu’un environnement de base pour les extensions très intéressantes que sont Polyglot Maven et Maven Shell.

Nous publierons rapidement un article plus détaillé sur l’ensemble des nouveautés à venir sur Maven 3.x.

RIA

GWT version 2.0 RC1

Une nouvelle version majeure du RIA de Google, GWT, sort en version 2.0 RC 1. Cependant, aucune date de sortie n’est encore annoncée.
Cette version s’accompagne d’un plugin pour Eclipse, nommé Google Plugin for Eclipse 1.2 RC1, dont l’on recommande vivement la mise à jour.
Parmi les nouveautés, on peut citer:

• Utilisation du Development Mode (anciennement appelé Hosted Mode) dans le navigateur de votre choix via un plugin.
• Possibilité de fragmenter le code JavaScript généré en plusieurs morceaux en utilisant GWT.runAsync() va permettre d’accélérer considérablement les temps de chargement.
• Story Of Your Compile (SOYC) génère un rapport sur le processus de compilation et permet d’avoir une meilleure vision du code généré.
• Facilitation de la création d’IHM par déclaration avec Ui Binder.
• Apparition d’un ClientBundle, similaire au ImageBundle, qui permet la généralisation du sprinting à d’autres formats les fichiers textes, css, etc.
• Utilisation de HtmlUnit pour les tests unitaires, qui permet maintenant de débugger directement dans le débuggeur Java.

Les nouveautés sont donc nombreuses et apportent un réel gain de productivité.
Le combat auquel se livrent actuellement les RIA est loin d’être terminé…

Le coin de la technique

OWASP Security Top Ten, la cuvée 2010 est arrivée

Après le Beaujolais Nouveau et le calendrier des pompiers, c’est au tour de l’OWASP de faire son annonce avec la mouture 2010 de son « Security Top Ten ». En attendant de rédiger un billet complet sur ces failles et leur prévention en Java, voici un lien vers une présentation que nous avions fait pour une formation interne et la liste 2010 avec une présentation très succincte des parades dont nous disposons en Java :

A1 – Injection : injection sql, hibernate ql, jpa ql, http, etc.
Utiliser des prepared statements, les paramètres de commons http, etc.

A2 – Cross Site Scripting (XSS)
Utiliser JSR 303 Bean Validation pour valider les données entrantes et escaper les données sortantes avec JSTL ou un équivalent.

A3 – Failles d’Authentification et de gestion de Gestion de Session
Utiliser Spring Security ou les mécanismes du moteur de servlet.

A4 – Référence Directe Non Sécurisée aux Objets de données
Revalider tous les ID provenants des requêtes HTTP ou utiliser un aliasing par random (cf. org.owasp.esapi.AccessReferenceMap).

A5 – Cross Site Request Forgery (CSRF)

Protéger les invocations d’URL par le contrôle d’un nombre aléatoire généré côté serveur. En cas de risque majeur, utiliser un framework Web de description de flow (Spring Web Flow, JBoss Seam, etc).

A6 – Mauvaise configuration de sécurité (Nouveau)
Utiliser les installation standard des systèmes d’exploitation et des middlewares, restreindre les droits des utilisateurs unix, etc.

A7 – Mauvaise protection des URL

Utiliser des mécanismes de sécurité déclarative par URL ou par annotation sur les beans controlleurs et de service.

A8 – Utilisation de redirects et forwards non controlés (nouveau)

Ne pas construire l’url de redirection ou de forward avec des données saisies par l’internaute. Figer les valeurs possibles de redirection dans le code ou dans des fichiers de configuration.

A9 – Failles des systèmes de stockages encryptés

Ne jamais stocker un mot de passe en clair, éviter de stocker des informations sensibles comme les numéros de carte bleue, . Si c’est finalement nécessaire, mettre en place un système de stockage dédié avec une gestion très attentive.
Documenter dans les configurations de logging (e.g. log4j.properties) les loggers à ne pas activer si des informations sensibles ne doivent pas sortir dans les logs (e.g. couche de binding des frameworks web).

A10 – Protection insuffisante des canaux de communication

Ne pas réinventer de canal de transport sécurisé, utiliser SSL quand c’est possible ; sinon, regarder WS-Security même s’il est très couteux à mettre en œuvre (debugging, etc).

Que devient Spring Rich Client ?

Spring Rich Client est un framework applicatif basé sur Spring. Il permet de créer des applications clients lourds plus facilement qu’en utilisant l’environnement Swing de base.

La promesse est séduisante, toutefois le projet initié en 2004 ne s’est vu finalisé que 4 ans plus tard, en mars 2008. Dès lors certains doutes planent quant à la santé de cette communauté.

Lieven Doclo, leader du projet, en a présenté les fonctionnalités lors d’un BOF à Devoxx. Ce fut également l’occasion d’un certain nombre de questions quant à la santé et au positionnement de ce projet méconnu :

• Bien qu’il soit directement référencé au sein du portfolio de SpringSource, l’éditeur n’investit pas dans ce projet. On notera d’ailleurs que Lieven Doclo n’est pas employé par SpringSource mais consultant Java externe.
• Le projet souhaite se positionner face à Eclipse RCP et NetBeans RCP en mettant en avant l’obligation d’utiliser SWT pour le premier et le manque de perspectives pour le second du fait des récentes déclarations d’Oracle.
• Les évolutions lentes du projet s’expliquent par la taille réduite de l’équipe. Lieven Doclo appelle d’ailleurs les volontaires à le rejoindre.

Si l’utilisation du framework Spring pour l’assemblage des composants des applications Spring RC est attirante car elle permet de reproduire les paradigmes de programmation utilisés pour le développement d’applications Web, Spring Rich Client peine encore à convaincre face aux poids lourds que sont les solutions d’Eclipse et de Netbeans. Il pourra toutefois intéresser les équipes souhaitant réutiliser des composants Spring existants.

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

Devoxx 2009

La semaine dernière se tenait l’édition 2009 de Devoxx à Anvers. Retrouvez nos premiers billets sur cette semaine de conférence :

• Devoxx – Jour 1 – Adobe University
• Devoxx – Jour 1 – Applications robustes avec Amazon EC2
• Devoxx – Jour 1 – Kanban in action
• Devoxx – Jour 1 – JSF 2
• Devoxx – Jour 1 – NoSQL avec HBase
• Devoxx – Jour 2 – Google App Engine
• Devoxx – Jour 2 – Les effets avec Flex 4
• Devoxx – Jour 2 – Hibernate Search
• Devoxx – Jour 2 – Java FX The developer guide
• Devoxx – Jour 2 – SOA en pratique
• Devoxx – Jour 2 – Scala Actors

Actualité éditeurs / SSII

• Innovation permanente chez Google
• Java SE 5 en fin de vie, JDK 7 en approche

SOA

• 10 mythes au sujet des SOA

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

• Soirée Google au LyonJUG

Actualité éditeurs / SSII

Innovation permanente chez Google

Google est encore une fois au cœur de l’actualité cette semaine avec la mise à disposition d’un nouveau langage de programmation et d’un protocole destiné à remplacer HTTP.

Le langage Go est à la croisée de C, Java et Pascal et est annoncé comme ayant des performances proches du C. Go se distingue par le fait que son compilateur produise directement du code natif, et qu’il ne requiert donc pas de machine virtuelle. Il apporte toutefois un ramasse-miette et un ensemble d’abstractions permettant de simplifier la programmation parallèle.

Très rapidement, plusieurs opinions et résultats d’expérimentations sont apparus. Ainsi, Tim Yang montre les performances obtenues par une application serveur développée en Java (en utilisant Mina), C (avec Nginx) et Go. Les résultats qu’il obtient montre que Go est en retrait par rapport aux deux autres solutions. Ces résultats doivent toutefois être relativisés par la maturité acquise par le système d’entrée / sortie de la JVM, le design très performant offert par Mina, la réputation de performance de Nginx et enfin, bien sûr, par le stade embryonnaire de Go.

Google a également diffusé les spécifications de SPDY (prononcer Speedy), un protocole visant à remplacer HTTP. On le sait, HTTP n’est pas adapté au Web moderne. En particulier il n’est pas optimisé pour obtenir une latence minimale. SPDY ne redéfinit pas tout, il se base sur HTTP et y ajoute un ensemble de possibilités supplémentaires telles que la compression d’en-têtes, le multiplexage de flux ou encore la priorisation de requêtes.

Des tests sur le transport du contenu des sites Web les plus populaires, permettent à Google d’annoncer un gain moyen de 55%.

L’entreprise américaine continue donc d’impressionner par son innovation permanente, n’hésitant pas à remettre en cause régulièrement des technologies considérées comme incontournables.

Java SE 5 en fin de vie, JDK 7 en approche

Sur la page dédiée à J2SE 5.0, Sun notifie depuis début novembre les utilisateurs de l’arrivée en fin de vie (End of Service Life) de cette version de Java.

Arrivé il y a 5 ans, Java 5 avait constitué la mise à jour la plus importante de la plate-forme et de son langage depuis sa création. Son adoption en entreprise fut longue, mais s’est concrétisée au fil du temps. Ainsi aujourd’hui, on ne compte plus qu’une minorité de projets fonctionnant encore exclusivement avec la version 1.4 ou inférieure de Java.

Il en est tout autrement pour Java 6.0. En effet, contrairement à la version 5.0 dont l’adoption était indispensable pour profiter des technologies d’entreprise les plus récentes, les principales motivations pour passer à la version 6.0 concernent la JVM elle-même et les améliorations qu’elle a connue.

L’arrivée en EOSL pourrait accélérer les choses dans certaines entreprises, tandis que d’autres préfèreront se tourner vers l’offre Java for Business de Sun qui permet de continuer de bénéficier du support de l’éditeur.

Une autre possibilité pourrait se trouver dans l’arrivée de JDK 7. En effet, la roadmap du projet promet un début de phase Release Candidate débutant à la fin du premier trimestre 2010 pour une durée d’un à deux mois, ce qui permettrait donc l’arrivée d’une version finale dans 6 mois. Si la confiance dans les dates de finalisation annoncées de JDK 7 s’est évaporée au fil des reports successifs, la situation semble maintenant se stabiliser : Mark Reinhold vient d’annoncer la disponibilité de la M5 de JDK 7, en accord avec le calendrier prévisionnel de la roadmap. Quatre des fameuses évolutions du langage apportées par le projet Coin y sont implémentées et peuvent donc être d’ores et déjà testées.

SOA

10 mythes au sujet des SOA

Yefim Natis, de Gartner, a exposé durant l’évènement SOA in Action, dix mythes communs (et la réponse qu’il faut leur apporter) sur la mise en place d’une SOA.
Là où l’article porte à sourire, c’est que, pour une fois, la faute est partagée : cinq de ces mythes sont propagés par les fanatiques de la SOA, et sont mis en regard de cinq autres portés par les allergiques.

Pour les fanatiques, nous avons :

• Les services sont portés par l’IT et propagés vers les acteurs fonctionnels.
  Pour Yefim Natis, une SOA est un moyen pour l’IT de mieux comprendre et appréhender les problématiques métier.
• Les plate formes orientées services reposent sur des briques pré-fabriquées.
  Les SOA ne reposent pas uniquement sur des applications ‘services’, mais aussi sur des batchs et des applications héritées.
• Partager et réutiliser sont les principaux apports d’une SOA.
  C’est en effet un des bénéfices attendus, mais c’est loin d’être le seul. On peut citer : meilleure exploitation, meilleure montée en charge …
• Mettre en place une SOA permet de s’abstenir de réaliser une phase d’intégration.
  Même si la SOA permet d’introduire une stabilité dans les interactions entre services, elle ne dispense pas de réaliser de vrais tests d’intégration, bien au contraire.
• Une SOA réduit les coûts du SI.
  Sur le long terme, peut être … Mais dans un premier temps, une SOA peut s’avérer couteuse : nouvelle façon de penser, nouveaux outils, formations à prévoir…

Pour les allergiques, la liste est la suivante :

• Une SOA introduit une grande complexité et de nouveaux problèmes.
  La plupart des problèmes liés à la mise en place d’une SOA sont des problèmes existants partout ailleurs dans le monde de l’informatique distribuée. La mise en œuvre d’une SOA ne fait souvent que mettre en exergue des problèmes existants.
• SOA n’est pas nouveau, c’est juste un effet de mode.
  Il faut voir au delà de l’aspect technique : certes SOA repose sur les principes de l’informatique distribué, mais c’est l’ensemble de la démarche qui est nouvelle et qui a au moins l’avantage de crystaliser certaines bonnes pratiques.
• Une SOA est vouée à l’échec, parce que les Web Services sont un standard trop instable.
  SOA et SOAP sont deux choses complètement différentes. Les Web Services sont ‘juste’ un moyen d’exposer des services.
• Il est difficile de vendre une SOA, car les acteurs fonctionnels n’en voient pas les bénéfices.
  Certains bénéfices sont apparents de manières quasi instantanée (on pense aux indicateurs BAM), et les acteurs fonctionnels gagnent rapidement une nouvelle compréhension de leur environnement IT.
• SOA est déjà dépassé, il faut passer à la suite.
  Le challenge d’une SOA basique est en effet dépassé. Mais il reste de nombreux enjeux à adresser, notamment dans les architectures les plus complexes.

via InfoQ

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

Soirée Google au LyonJUG

Lundi 23 Novembre, le LyonJUG organise une soirée dédiée aux technologies Google. L’occasion de découvrir, démonstration à l’appui, Google Web Toolkit, Google App Engine, Android et le dernier né Google Wave. L’objectif est aussi de présenter l’architecture globale de ces produits pour mieux en saisir le fonctionnement et le but.
Pour faciliter l’organisation de la soirée dans les locaux d’EPITECH, vous devez vous inscrire ici.

Actualité éditeurs / SSII

• La fondation Eclipse se prépare à Servlet 3.0 avec Jetty 7.0
• Sonar 1.11

RIA

• Air ‘Athena’
• DHTMLX 2.5
• Tips and Tricks Maven 2

Le coin de la technique

• Sécurité : 5 choses de plus que les agresseurs d’applications web ne vous diront pas
• Les optimisations du JDK 6u14 activées par défaut sur le JDK 7

Actualité éditeurs / SSII

La fondation Eclipse se prépare à Servlet 3.0 avec Jetty 7.0

La fondation Eclipse nous livre une nouvelle version de Jetty estampillée 7.0. Côté nouveauté, pas grand chose à vrai dire. Il y a évidemment l’habituelle série de corrections de bugs et d’améliorations de performance. Cette nouvelle version marque surtout le début de la route vers l’implémentation des servlets 3.0 prévue pour Jetty 8.0. C’est aussi l’occasion pour Eclipse d’assimiler un peu plus le projet en changeant principalement le package ancêtre de org.mortbay vers org.eclipse, gare au refactoring donc. A noter tout de même, Jetty est maintenant livré sous une forme modulaire pleinement compatible OSGI. Webtide en profite pour livrer la même version de Jetty, en y intégrant des modules additionnels:

• JSP de glassfish
• JTA d’atomikos
• plugin maven
• integration d’ant
• configuration Spring

Jetty 6 sera encore maintenu pendant quelques temps (aucune précision de la part d’Eclipse), tous les nouveaux développements seront faits sur Jetty 7, et la branche 8 sera en pré-release dans les prochains mois et supportera l’API Servlet 3.0.

• L’annonce sur la ML
• La news d’InfoQ
• La page Jetty chez Eclipse
• La page Jetty chez Codehaus

Sonar 1.11

SonarSource nous gratifie d’une version 1.11 du désormais célèbre outil de suivi de qualité Sonar. Comme souvent, de nombreux de bugs ont été corrigés. Parmi les améliorations, on peut noter les passages à Hibernate 3.3 et GWT 1.7. Au chapitre des nouvelles fonctionnalités, la possibilité de réutiliser les fichiers de configuration PMD et CheckStyle définis dans le pom permettra de plus aisément éviter les doublons.

SonarSource tente de faciliter la vie des développeurs de plugins avec l’apparition d’un archétype Maven pour créer des plugins Sonar. D’autres nouveautés d’API, comme le filtrage de widgets suivant différents critères (comme le rôle utilisateur ou la langue choisie), ajoutent de la flexibilité.

• L’annonce sur le blog Sonar avec plein de jolies images.
• La release note.

RIA

Air ‘Athena’

Non, ce n’est pas une nouvelle marque de baskets, mais, comme les flexeurs le savent depuis le Flash Camp de mai, le nom de code de la future version de Adobe Air, la version 2.0. Comme on s’y attendait, celle-ci fonctionnera avec Flash 10 et Flex 4. Même si aucune date officielle n’a été avancée, Adobe dévoile peu à peu les principales évolutions de sa plate-forme, nouveautés répertoriées par Elad Elrom sur InsideRIA.
Commençons par celle qui nous semble vitale dans l’adoption de AIR / Flex à grande échelle, à savoir une amélioration drastique des performances. Les équipes d’Adobe ont mis l’accent sur la réduction des ressources (CPU et mémoire) consommées par le runtime AIR. Les tests effectués sur une mini application montrent en effet une diminution des ressources utilisées (en regard de la version 1.5). Reste à tester ces optimisations sur une application gourmande… Toujours au chapitre performance, Adobe promet une optimisation de Webkit (le browser open source embarqué par AIR) et une installation Linux native.
Au menu des nouveautés, nous avons :

• Une meilleure connaissance de la plate-forme matérielle, avec la gestion des devices multi-touch et la gestion des périphériques de stockage USB ou réseau ‘à chaud’.
• Un enrichissement des fonctionnalités des APIs existantes : points de sauvegarde dans les transactions, support IPv6, augmentation de la taille maximale de la fenêtre AIR, manipulation des données de l’API Microphone, time-out d’inactivité…
• De nouvelles fonctionnalités via de nouvelles API, dont la plus étonnante est l’API File promises. Celle-ci permet de télécharger en local, depuis une application AIR, un ensemble de fichiers par simple Drag & Drop. D’autres API font également leur apparition, en particulier au niveau du support réseau et de l’adhérence de AIR à l’OS (les fichiers peuvent maintenant être ouverts par des processus natifs de l’OS, par exemple Notepad pour un .txt sous Windows).

Une évolution assez naturelle donc (correction des gros points de blocage des versions précédentes), mais quelques promesses de fonctionnalités intéressantes, en particulier via l’adhérence à l’OS.

DHTMLX 2.5

Des nouvelles de DTHMLX (la 11ème librairie de notre revue de presse de fin janvier dernier) qui est sorti il y a quelques semaines en version 2.5.

Cette release apporte plusieurs corrections et améliorations sur tous les composants de la suite. On retiendra plus particulièrement :

• Une API orientée objet (l’API fonctionnelle est toujours disponible) ,
• Nouvelle skin par défaut avec d’ici peu (mais non présent dans cette release) un Skin Customizer qui permettra de modifier facilement les couleurs principales du thème standard,
• Nouveau moteur de rendu qui améliore la performance d’affichage des composants Layout, Windows, Accordion et Tabbar,
• Une API de conteneurs unifiée (toujours pour les Layout, Windows, Accordion et Tabbar),
• Améliorations générales pour les composants Grid, Tree et TreeGrid,
• Révision complète du DocsExplorer.

Puisque nous sommes sur DHTMLX, notons aussi le composant Scheduler v.2.0, sorti en juillet dernier, qui n’est pas inclus dans la suite mais qui vaut tout de même le détour si vous avez besoin d’un composant calendrier haut niveau.

Les téléchargements se passent par ici et comme d’habitude vous aurez le choix entre le téléchargement composant par composant ou le téléchargement de la suite complète.
Chaque composant existe en édition standard ou professionnelle. Pour résumer la version standard contient moins de fonctionnalités et est sous licence GPL alors que la professionnelle contient toutes les fonctionnalités, un support prioritaire en cas de bugs/questions sur le forum et plusieurs centaines d’exemples de fonctionnalités avancées.
Pour le détail des licences et des différents prix proposés pour les composants et pour la suite complète, cela se passe sur cette page.

Tips and Tricks Maven 2

Sonatype nous présente ici quelques nouveautés intéressantes de maven disponibles depuis la version 2.1 concernant les projets multi-modules. Cela se traduit par de nouvelles commandes disponibles telles que:

• -rf, -resume-from: permet de spécifier au maven reactor le projet à partir duquel on veut reprendre le build
• -pl, -projects: permet de sélectionner une liste de modules d’un projet multi-modules
• -am, -also-make: combinée avec l’option -pl, elle permet de construire tous les modules dépendants du module passé à l’option pl
• -amd, -also-make-dependents: combinée avec l’option -pl, elle permet de construire tous les modules qui ont une dépendance vers le module passé à l’option pl

Très bonne nouvelle donc pour les développeurs dont le build prenait beaucoup de temps à cause de la reconstruction de modules non modifiés (et non impactés) par leurs nouveaux développements.

Le coin de la technique

Sécurité : 5 choses de plus que les agresseurs d’applications web ne vous diront pas

Le Denim Group continue sa série 13 Things a Web Applications Attacker Won’t Tell You que nous avions traitée la semaine dernière avec 5 nouvelles failles de sécurité de nos applications web :

• Ce n’est pas parce que vous utilisez un framework de sécurité que votre application est sécurisée.
• Je n’utilise pas un browser pour attaquer votre application web.
• J’adore quand votre site me permet d’uploader des fichiers dans l’arborescence des répertoires servis par l’application web.
• Je peux intercepter et voler toutes les informations qui passent sur HTTP si elles ne sont pas protégées par SSL ou un mécanisme équivalent.
• Une sécurité obscurantiste n’en est pas une (ne pas savoir faire ou se dire que ca n’arrivera pas ne protège pas).

Si le dernier point est un débat éternel chez les experts de la sécurité les premiers sont en revanche communément admis.

Les optimisations du JDK 6u14 activées par défaut sur le JDK 7

Rémi Forax, un contributeur sur OpenJDK et sur la JSR-292, a fait part de son étonnement en constatant un gain significatif de performance entre deux builds successifs de l’OpenJDK 7 actuellement en cours de développement. C’est ainsi qu’il a pu se rendre compte que deux optimisations majeures du compilateur JIT de la JVM étaient activées par défaut depuis le build 72 du projet : l’escape analysis et la compression de pointeurs. Celles-ci étaient apparues dans le JDK 6u14 mais n’y étaient pas activées par défaut.

Pour rappel l’escape analysis consiste en l’analyse du bytecode d’une méthode pour découvrir les références vers les objets qui ne « s’échappent » pas du contexte de la méthode. Grâce à cette analyse, la JVM peut alors décider d’allouer ces objets directement sur la stack plutôt qu’en heap comme c’est normalement le cas. Il en résulte un gain de performance évident puisque le coût d’allocation et de libération de mémoire est alors supprimé pour ces objets.

La compression de pointeurs, quant à elle, concerne uniquement les JVM 64 bits. En effet le passage d’un adressage de 32 à 64 bits entraîne une consommation plus élevée de la mémoire du fait de l’augmentation de la taille des pointeurs, induisant elle-même des temps de chargement plus longs et une surconsommation du cache du processeur. Pour palier ce problème, la compression de pointeurs se base sur le fait que la JVM aligne l’adresse des objets sur 64 bits (ceci afin de simplifier et donc d’accélérer leur accès en mémoire), pour procéder à un scaling des pointeurs. Ainsi, en limitant l’espace mémoire adressable à 32 Go, il est possible de contenir un pointeur dans 32 bits et donc de revenir à une consommation mémoire proche de celle d’une JVM 32 bits.

L’activation par défaut de ces deux optimisations sur le JDK 7 montre que l’équipe du projet estime désormais qu’elles ne sont plus expérimentales et qu’elles conviennent dans la majorité des cas. Ismael Juma précise par ailleurs qu’il est possible que ces activations par défaut soient reportées également au JDK 6 courant 2010.

Actualité éditeurs / SSII

• JavaRebel et Eclipse RCP deviennent…

Agilité

• Les clés d’une rétrospective réussie

RIA

• Prototype 1.6.1, une version pas si mineure
• Tester vos services AMF avec soapUI
• Vaadin 6.1.0

Le coin de la technique

• Ces classes que vous en avez assez de réécrire

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

• Soirée qualité du logiciel au Paris JUG
• Conférence CITCON le 18 et 19 septembre

Actualité éditeurs / SSII

JavaRebel et Eclipse RCP deviennent…

Des nouvelles de JavaRebel et d’Eclipse RCP dont nous évoquions le processus de changement de nom dans de précédentes revues de presse (ici et là).

Nous avons donc (roulement de tambour) JavaRebel qui devient… JRebel ! Il rejoint donc la longue liste des J* tel que JFreeChart, JUnit…

En ce qui concerne Eclipse RCP, les votes nous donnent comme gagnant… Eclipse RCP ! Statu quo donc avec 38% des votants pour conserver le nom actuel, suivi d’Eclipse Platform, Aurora, Corona et Tangram.

Agilité

Les clés d’une rétrospective réussie

La rétrospective est l’un des outils les plus connus et plus utilisés dans le processus d’amélioration continue. Pour obtenir de meilleurs résultats, quelques principes simples doivent être respectés. Cette semaine, un article publié sur InfoQ revient sur les éléments clés d’une rétrospective agile réussie :

• La préparation : la majorité des gens ont peur de donner leur position à l’oral et en public, c’est pourquoi il est important d’expliquer a priori les règles du jeu et expliciter les attentes et les enjeux de ce genre de réunion. L’efficacité de ce genre de réunion est proportionnelle au taux de participation : il faut tout faire pour éviter les monologues de quelques-uns
• La participation : il faut absolument éviter que cette séance ne devienne une routine, faire une rétrospective pour faire une rétrospective ne sert à rien : non aux retros théâtrales! C’est pourquoi il est important d’en sortir des actions concrètes et réalisables. Celles-ci permettent de mesurer leur efficacité et de donner une dynamique positive et concrète au processus d’amélioration continue.

Vous pouvez ajouter à ces deux points clés ces quelques conseils de communication :

• N’hésitez pas à ouvrir le débat et à poser la question : « Quelqu’un a t-il d’autres points à aborder ? »
• Demandez aux participants des pistes d’amélioration pour la rétrospective elle-même
• Dites merci !

RIA

Prototype 1.6.1, une version pas si mineure

Parce qu’il n’y a pas que jQuery dans la vie, voici quelques nouvelles de Prototype qui sort en version 1.6.1 (par Ajaxian)

Outre le changement de co-leads, les principales nouveautés portent sur :

• Compatibilité avec les navigateurs et particulièrement le support complet de Chrome 1.0+ et IE8
• Sauvegarde de données sur un élément DOM (la fonction data de jQuery)
• Nouveaux évènements souris mouseenter et mouseleave disponibles pour tous les navigateurs (et plus seulement IE)
• Performances générales : méthodes plus rapides, clean up plus efficaces…
• Utilisation de Sprockets pour la gestion de dépendances
• Documentation en ligne avec PDoc

De nombreux changements donc, à la fois au coeur de la librairie mais aussi au niveau des fonctionnalités, de la documentation…
Le téléchargement se passe par ici.

Tester vos services AMF avec soapUI

Dans cet article, nous apprenons qu’il est possible de tester les applications Flex utilisant le protocole AMF avec soapUI. Pour rappel, AMF (Action Message Format) est un protocole binaire de transfert de données entre le client et le serveur, permettant l’accès à des objets sur ce dernier (Java par exemple).
Avec une configuration relativement simple et quelques astuces, il devient très aisé de tester votre flux AMF : avec un simple script Groovy ainsi que les librairies BlazeDS et XStream, un flux ASObject est généré au format XML, permettant d’effectuer les tests.
Cerise sur le gâteau, des tests de charge peuvent être exécutés et démontrent encore une fois les bonnes performances de ce protocole.
Pour finir, nous apprenons également que la prochaine version de soapUI (3.5) intégrera le support de nouveaux protocoles, dont AMF ! A surveiller.

Vaadin 6.1.0

Vaadin continue son petit bonhomme de chemin et sort, fin de semaine dernière, en version 6.1.0 (par The Server Side).

Après la release majeure de juin dernier, qui a vu notamment le renommage du produit, le plugin eclipse et l’éditeur WYSIWYG, cette nouvelle version nous apporte entre autres (release notes complète) :

• Disponibilité du produit sur le repository central de Maven
• Support de Google App Engine (le build et le déploiement se font par leur plugin eclipse)
• Correction de 87 Jiras

Le téléchargement se passe par ici et n’oubliez pas le book of Vaddin qui parcourt le produit de a à z (installation, initialisation d’un projet, tutoriels…).

Le coin de la technique

Ces classes que vous en avez assez de réécrire

Dans le cadre de la sortie du JDK 7, Joe Darcy, de Sun, a demandé à un groupe de discussion de l’OpenJdk de réfléchir aux méthodes qui pourraient voir le jour dans la classe java.util.Objects. Cette classe (comme son nom ne l’indique hélas pas du tout) est destinée à regrouper des méthodes utilitaires fréquemment réécrites et utilisées.
Dans son message initial, il expose sans surprise un equals(arg1, arg2) tolérant la nullité. Un peu plus surprenant, il propose un compareTo(arg1, arg2) pour les primitifs.

Au premier abord, on sent l’idée de réintégrer dans le JDK des classes utilitaires déjà présentes dans nos frameworks (Apache Commons Lang ObjectUtils et Spring ObjectUtils) comme on l’a connu avec succès dans le Collections Framework mais aussi avec des flops comme java.util.logging qui n’a pas réussi à remplacer log4j ni à innover comme slf4j.

Si l’on continue la réflexion, on retrouve cette idée de protection contre les NullPointerException qui nous font tant souffrir comme le rappelle Tony Hoare dans Null References The-Billion Dollar Mistake. Sous cet angle de vue, l’idée de Joe Dary nous ramène à deux autres tentatives pour colmater les nulls en java avec JSR 305: Annotations for Software Defect Detection et JSR 303: Bean Validation qui proposent respectivement @NonNull et @NotNull !

Ces efforts pour lutter contre les NullPointerException en Java sont louables mais ils laissent un goût de contournement d’une limitation structurelle alors que d’autres langages sont intrinsèquement mieux armés (_safe operators_ à la Groovy, etc). Et nous entrons là dans un débat plus vaste : « Est-il trop tard pour améliorer le langage java lui-même quitte à perdre en compatibilité ? ».

Via InfoQ

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

Soirée qualité du logiciel au Paris JUG

Le Paris JUG fait sa rentrée mardi prochain sous le signe de la qualité. Au programme de cette soirée, le JUG nous propose pas moins de quatre présentations:

• Les frameworks opensource (Quels frameworks utiliser ? Quand ? Comment ?)
• Sonar, venez découvrir les 7 péchés capitaux du développeur et les chasser avec Sonar.
• SonarJ community edition, pour contrôler l’architecture et la qualité technique du code source.
• Squale, la plate-forme open-source de qualimétrie extensible.

Plus d’information sur l’évènement …
Le programme des prochaines soirées …

Conférence CITCON le 18 et 19 septembre

Comme un echo au Paris JUG, la conférence CITCON (Continuous Integration Testing CONference) a lieu à Paris, dans les locaux de l’ISEP.
Les sessions, type Open Space, seront organisées vendredi soir pour se dérouler toute la journée du samedi.
Vous pouvez retrouver les infos utiles sur le site de la conférence.

Architecture

• Gartner adopte le pragmatisme avec l’Architecture Émergente

Actualité éditeurs / SSII

• JBoss HornetQ

RIA

• BlazeMonster

Le coin de la technique

• Liste finale des évolutions du langage Java apportées par le JDK 7
• Fin d’Eclipse RCP, place à…
• TestSwarm

Architecture

Gartner adopte le pragmatisme avec l’Architecture Émergente

Gartner nous livre un plaidoyer pour la pragmatisme avec Emergent Architecture. La formulation est parfois compliquée mais on se réjouira de trouver la responsabilisation des équipes sur le terrain et des Architectes d’Entreprise évangélistes de lignes directrices. Pour reprendre une expression chère au Lean Manufacturing, « Empower the People » :

1. Non déterminisme – Dans le passé, les architectes d’entreprise prenaient des décisions centralisées qui s’appliquaient à tous. Dans une architecture émergente, ces architectes d’entreprise doivent au contraire décentraliser la prise de décisions pour permettre l’innovation.
2. Acteurs autonomes – Les architectes d’entreprise ne peuvent plus contrôler tous les aspects de l’architecture comme ils le faisaient auparavant ; ils doivent désormais reconnaître l’étendue et la variété du SI ; ils doivent déléguer le contrôle aux équipes sur le terrain.
3. Limiter les contraintes aux lignes directrices – Jusqu’à présent, les architectes d’entreprise ont fourni des spécifications détaillées de tous les aspects de l’architecture ; ils doivent désormais limiter leurs prescriptions aux lignes directrices et de permettre le choix.
4. Acteurs orientés objectif – Auparavant, les seuls objectifs qui comptaient étaient les objectifs de l’entreprise mais cela s’est maintenant déplacé et chaque acteur agit dans ses propres intérêt. Il ne faut pas pour autant oublier les lignes directrices.
5. Influences locales: Les acteurs sont influencés par des interactions locales et des informations limitées. Les feedbacks au sein de leur sphère de communication modifie leur comportement. Aucun acteur individuel ne possède la vision globale d’un système émergent. Les architectes d’entreprise doivent intensifier leur travail coordonner et de transmission de l’information.
6. Systèmes dynamiques et adaptatifs: le système (les différents acteurs et leur environnement) changent avec le temps. Les architectes d’entreprise doivent définir les pourtours des systèmes émergents et ajuster en fonction des changements.
7. Environnement aux ressources limitées: L’abondance, les budgets illimités, ne permet pas de créer une architecture émergente ; c’est au contraire la rareté des moyens qui permet une architecture émergente.

Actualité éditeurs / SSII

JBoss HornetQ

Après 2 ans de développement, le projet JBoss Messaging 2.0 sort enfin dans les bacs sous le nom HornetQ. Ce Message Oriented Middleware n’est pas une évolution de son prédécesseur qui continue d’exister dans sa version 1.0, mais belle et bien une réécriture (presque) intégrale. Redhat nous le vend comme un MoM opensource, multi-protocol, embarquable, haute performance, réparti, et asynchrone.
HornetQ peut-être utilisé en standalone ou bien embarqué dans un serveur d’application JBoss AS par exemple. Chose appréciable, HornetQ est léger, il dépend uniquement du JDK (5 minimum) pour être complètement fonctionnel.
Dans sa présentation, Redhat nous annonce que le projet est facile d’utilisation avec une documentation déjà très complète et la bagatelle de 65 exemples de codes sources. Il est même possible de démarrer en moins de 5 minutes.
HornetQ bénéficie d’une conception orientée Pojo qui lui permet d’être utilisé directement dans Spring ou Guice. La performance a fait l’objet d’une attention importante, avec un journal haute performance et JBoss Netty pour la scalabilité.
JBoss nous livre une liste sans fin des fonctionnalités embarquées parmi lesquels on retiendra:

• JMS 1.1
• JTA
• Adaptateur JCA

Enfin, l’editeur annonce orienter ses développements vers le support d’API RestFull qu’il voit comme le futur du cloud computing. Redhat souhaite donc pousser la porte des clouds privé en tentant de s’imposer comme le provider de message incontournable dans le nuage.

• Site du projet
• Wiki

RIA

BlazeMonster

BlazeMonster vient de sortir dans sa deuxième version. Pour rappel cet outil, basée sur la technologie AIR, permet le support et l’aide à la génération de code pour consommer/exposer des services Java en tant que service Remote pour BlazeDS ou LCDS (LiveCycle Data Services).
Parmi les supports, nous avons entre autre :

• Génération des fichiers de configurations : déclarations des services, channels..
• Génération du code appelant le service Remote
• Génération des beans ActionScript (Value Object)
• Visualisation des réponses des services Remote

Dans cette deuxième version, BlazeMonster intègre le support de Spring BlazeDS, permettant la génération de services Remote en utilisant cette librairie. Je vous invite à jeter un coup d’œil sur les autres corrections et évolutions apportées à ce projet ici.
Facile d’utilisation, ce projet permet de copier/coller des morceaux de code dans votre application, facilitant le développement.
Enfin, à travers ce projet nous voyons, une fois de plus, l’engouement que les technologies Flex et BlazeDS remportent. Peut être pouvons nous espérer l’intégration de ce type d’outil dans le Flash Builder 4. Alors messieurs d’Adobe, qu’attendez vous ?

Le coin de la technique

Liste finale des évolutions du langage Java apportées par le JDK 7

En début d’année, Sun a initié le Project Coin, un sous-projet d’OpenJDK visant à recueillir les propositions d’évolutions du langage Java pour le JDK 7 prévu pour début 2010. Les soumissions ont été nombreuses et Joseph D. Darcy, leader du projet, informait régulièrement la communauté sur l’avancement du processus de sélection. C’est maintenant la liste finale des évolutions qu’il annonce. Sauf problème de planning, il s’agit donc là de ce que le langage Java sera dans JDK 7 :

• Clause switch utilisable sur les String.
• Gestion automatique des resources. Cette évolution vise à simplifier la gestion de la fermeture des flux ou autre ressources par l’utilisation d’une clause try spécifique pour les objets implémentant l’interface Disposable introduite dans le JDK pour l’occasion.
• Inférence de type améliorée pour la création d’objets génériques grâce à une syntaxe du type List<String> list = new ArrayList<>().
• Evolution de la gestion des warnings pour l’utilisation des generics dans des varargs.
• Autorisation de la notation binaire pour les entiers comme en C/C++ et possibilité de placer des underscores dans les nombres pour en simplifier la relecture tel que long creditCardNumber = 1234_5678_9012_3456L
• Accès en lecture et écriture aux valeurs des collections Java par la notation utilisé jusqu’alors uniquement pour les tableaux.

On est loin de la liste d’évolutions très audacieuses initialement prévue pour JDK 7, mais les évolutions finalement retenues ont l’avantage d’être réalistes en terme de temps d’implémentation, tout en apportant un confort supplémentaire au quotidien pour les développeurs Java.

Rémi Forax, très au fait des développements sur l’OpenJDK, propose d’ailleurs son analyse des tâches restant à accomplir et de leur complexité pour chacune des évolutions.

Fin d’Eclipse RCP, place à…

Après Java Rebel, c’est Eclipse RCP qui se trouve sur la voie du changement de nom.
Cette fois-ci, ce n’est pas pour une raison de marque déposée mais tout simplement, dixit l’auteur, parce que ce nom est horrible .
Un vote est organisé avec tous les noms remontés par la communauté Eclipse depuis 3 mois.
Alors, Aurora, Montage ou Tangram, c’est à vous de voter ! Et ça se passe sur cette page.

TestSwarm

John Resig, créateur de jQuery, nous annonce que Test Swarm est maintenant ouvert au public (par ajaxian).

Test Swarm permet de tester le code Javascript sur différents navigateurs de différentes plateformes de manières continues. A l’origine utilisé pour jQuery, il est désormais possible de tester son propre code Javascript, moyennant 8 steps d’installation paragraphe Setting Up Your Own Swarm. Les tests (jobs) peuvent être lancés à chaque commits (SVN ou Git) ou bien en appelant une URL spécifique. Les résultats des tests sont résumés dans un tableau avec une colonne pour chaque navigateur/plateforme. Il est possible de rester au niveau projet mais on peut affiner l’affichage au niveau commit voir au niveau de chaque fichier js de tests. Côté couleur, les tests vert se sont bien passés, les rouges contiennent au moins une erreur, les noirs ont au moins une erreur critiques et les gris sous en cours/en attente. Des logs sont disponibles pour chaque run de tests et permettent de voir ceux qui ne seraient pas passés.

Les frameworks de tests unitaires Javascript gérés (bien d’autres suivront) sont pour l’instant :

• QUnit (jQuery)
• UnitTestJS (Prototype)
• JSSpec (MooTools)
• JSUnit
• Selenium
• Dojo Objective Harness

Une vidéo de type quick tour nous donne un bon aperçu du site. Plusieurs directions sont possible concernant la roadmap du produit dont l’intégration à l’IDE, tests sur encore plus de browser… Un produit à suivre.

• La modularité : introduite par le projet Jigsaw, actuellement au cœur d’une polémique, elle devrait permettre de supprimer les principaux reproches faits aux précédents JDKs, à savoir leur lenteur au démarrage, le plat de spaghettis des dépendances, et l’enfer du classpath.
• La JVM polyglotte : capable d’exécuter de nombreux langages (la voie a été ouverte par JRuby), elle devrait faciliter l’émergence des langages dynamiques. C’est le projet DaVinci.
• Les ajouts au langage : ils sont listés dans le projet Coin. Danny a listé les switch sur les String, la gestion d’exceptions multiples, une meilleure inférence de type, et l’opérateur Elvis
• Plus d’APIs I/O : le Path remplace le File, manipulation des Directory, recherche en utilisant des FileVisitor, opérations asynchrones. On peut se demander si ce genre de fonctionnalités sera vraiment cross-platform (comportement identique ?).
• Nouveau Garbage collector : le fameux G1 (dont nous avons parlé ici) est disponible en preview dans le JSE 6 update 14 en utilisant l’option -XX:+UnlockExperimentalVMOptions -XX:+UseG1GC

La final release devrait être disponible (selon la roadmap annoncée) dans le courant du premier trimestre 2010.

On apprécie les efforts continus faits sur la VM mais nous regrettons que les évolutions du langage restent superficielles (c’est bien mais pas suffisant). C’est probablement l’une des raisons de l’émergence des langages dynamiques. Comme si Danny Coward avait voulu légitimer l’opening keynote de James Gosling : « la force de Java ce n’est pas son langage, mais sa VM ».

Actualité éditeurs / SSII

• Coopération entre SpringSource et Adobe
• tc Server : SpringSource signe la première offre open source professionnelle sur Tomcat

Le coin de la technique

• Les orientations de GWT : Roadmap GWT 1.6
• Java 7, ce n’est pas pour tout de suite…
• Sortie de Grizzly 1.9
• Présentation de Google Guice 2.0

Actualité éditeurs / SSII

Coopération entre SpringSource et Adobe

SpringSource renforce son positionnement sur les RIA en signant un accord de partenariat avec Adobe Systems. Un partenariat dont l’objectif est de simplifier le développement et le déploiement des applications RIA se basant sur Adobe Flex et Spring.

Adobe et SpringSource se sont alliés pour travailler sur Spring BlazeDS Integration, un projet open source qui vise à simplifier l’intégration de Spring avec Adobe’s BlazeDS. Une version bêta est prévue dans une ou deux semaines.

SpringSource a prévu pour l’année prochaine un nouvel adaptateur pour Adobe LiveCycle Data Services ES, qui permet d’instaurer un moteur d’échanges de données entre les applications RIA basées sur Flex et Spring.

Ce rapprochement permet à SpringSource de renforcer son positionnement sur les RIA.

tc Server : SpringSource signe la première offre open source professionnelle sur Tomcat

Philip Hanik présente dans « SpringSource tc Server – The Tomcat you know. The enterprise capabilities you need. » le périmètre du nouvellement annoncé tc Server.

On y retrouve tous les ingrédients de la version commerciale d’un produit open source professionnel :

• Support : de l’entrée de gamme « heures ouvrées » à la formule « mission critique 24×365″ avec une réponse dans l’heure
• Packaging : livraison packagée avec les patchs nécessaires au client et des configurations et scripts de démarrage optimisés pour les différentes plateformes (32 vs 64 bits, etc).
• Indemnisation : en cas de problème juridique concernant la nature Open Source de Tomcat.
• Administration centralisée : ajout de mécanismes de gestion centralisée de serveurs Tomcat (configuration des serveurs, déploiement d’applications clusterisées [1] )
• Audit : suivi des opérations réalisées sur les serveurs.
• Monitoring et alertes : reprise des fonctionnalités de SpringAMS ( Hyperic HQ + extensions de monitoring de Spring Framework).
• Diagnostique : détection de thread lock, corrélation des erreurs avec les urls et les threads, mécanisme de First Failure Data Capture (FFDC).

Si les premiers points étaient déjà couverts par des offres de support commercial (e.g. SpringSource Enterprise Ready Server), c’est la première offre de type Open Core Licensing pour Tomcat (noyau open source + extensions commerciales orientées administration).
Les éditeurs incitaient jusqu’à présent leurs clients intéressés par un support Tomcat à faire un upsale sur serveur plus sophistiqué (JBoss App. Server, Websphere App. Server Community Edition, Spring dm Server, etc).

Quel intérêt de payer 500$/an/cpu pour tc Server plutôt que d’utiliser Tomcat ? Outre le support qui sera important pour de nombreux exploitants, les fonctionnalités d’exploitations et de supervision présentent un intérêt à prendre en compte.

Nous noterons pour conclure que l’ensemble des fonctionnalités annoncées ne sera pas disponible dès la version 1.0 de tc Server.

[1] tc Server permet notamment des opérations install/update/start/stop/uninstall/rollback phasées sur des clusters pour mettre à jour les noeuds les uns après les autres sans arrêt du service.

Le coin de la technique

Les orientations de GWT : Roadmap GWT 1.6

La version actuelle de GWT est la 1.5.3. L’équipe GWT a présenté sur son blog officiel les orientations de GWT 1.6 et des prochaines versions : What’s ahead for Google Web Toolkit.

Ainsi, on observe que l’équipe GWT s’attaque à différents points :

• Performance
• De compilation pour améliorer la productivité du cycle de développement
• D’exécution : optimisation de l’utilisation de la classe StringBuilder par exemple, des composants (cf LazyPanel plus bas)
• S’approcher des bonnes pratiques éprouvées dans la communauté Java : voici la spécification : Design Doc for 1.6 WAR structure. Ainsi, il sera possible de livrer les fichiers statiques (images, css) dans un répertoire hors de la WebApps. Actuellement tout est chargé via le classpath. Ces ressources statiques pourront être « akamai-llisées » et aussi relivrées indépendamment de la WebApp.
• Richesse des composants : intégration de nouveaux composants qui étaient dans l’incubateur de composants GWT
• Un calendrier : DatePicker
• Un Panel qui permet l’affichage du contenu d’un Panel lorsqu’on le souhaite afin d’améliorer les performances d’affichage : LazyPanel
• Migration de Tomcat à Jetty pour le Hosted Mode Server.

Cette version 1.6 est prévue pour le premier trimestre 2009.

Ils parlent aussi de la Roadmap GWT :

• Marwan KHELIF avec GWT 1.6 : quoi de neuf ?
• Thomas Recloux avec Roadmap GWT 1.6
• A voir aussi sur le site officiel de GWT Making Gwt Better

Java 7, ce n’est pas pour tout de suite…

Initialement prévu pour début 2009, nous n’avons toujours pas (peu) eu de détails officiels concernant celui-ci. Vous vous en doutiez, Java 7 ne sortira pas demain. Suite à une des conférences de Devoxx, nous en savons désormais un peu plus sur ce sujet : sa sortie décalée à début 2010.

Est-ce si lointain ? Pas vraiment, à la vue de tous les différents qui tournent autour du Jdk 7 (modularité, closures …), il ne sera probablement pas trop d’une année pour résoudre tous ces sujets de discordes. Pour y arriver, des choix rapides et judicieux devront être pris, cette même conférence en a d’ailleurs laissé sous-entendre quelques-uns, en voici les grandes lignes.

• Modularité : point central de Java7, après la mort programmée de la JSR-277, la réconciliation avec OSGi devra sans doute passer par la JSR-294 (sous-jacente) – les superpackages. Si quelques changements récents offrent des perspectives de réconciliation, l’aventure ne fait que commencer pour le sujet le plus sensible du Jdk 7. Le nouveau projet Jigsaw qui doit permettre de partager à la communauté l’avancement des travaux est déjà fortement controversé.
• Les closures : la grande blague ; le jdk7 ne proposera finalement pas cette fonctionnalité. Aucun consensus n’ayant été trouvé à ce sujet par la communauté : celles-ci sont pour le moment déscopées.
• Les nouvelles API : aucun scoop à ce sujet. Nous en connaissions déjà les principales : nio2 (JSR-203) et JodaTime (JSR-310).
• Évolutions du langage : C’est Joseph D. Darcy qui sera chargé de définir et regrouper les petites évolutions du langage pour le Jdk 7. Pour cette future nouvelle JSR (sa 3e après JSR-13 et JSR-269), il a prévu d’impliquer d’avantage la communauté pour ce point facilement sujet à controverse. Son idée est de proposer et demander les retours de la communauté en amont du processus pour éviter toute controverse. Avant même que la JSR ne soit proposée en draft, les grandes lignes de celles-ci devraient en être définies, disponibles et discutées sur un projet spécifique de l’open JDK. Cette JSR est prévue pour sortir au cours du premier semestre 2009.

À ce propos, vous vous demandez peut-être comment va-t-il s’y prendre pour intégrer ces changements ? C’est peut-être également l’occasion de revenir sur un de ces anciens articles présentant les différentes étapes à suivre pour ajouter des fonctionnalités dans le jdk .

Sortie de Grizzly 1.9

Grizzly 1.9 est sorti, à noter que la version 2.0 est prévue pour la fin de l’année. Grizzly est un framework Sun pour aider les développeurs à construire des serveurs robustes et scalables en utilisant l’API Java NIO (et NIO 2). Il met aussi à disposition le support de différents protocoles :

• Glassfish utilise Grizzly comme HTTP Listener.

  Les nouveautés de cette version sont :

  • Support des I/O asynchrones (NIO2, Xebia en avait parlé), cela permet d’améliorer grandement les performances
  • Support des HTTP write asynchrones
  • GrizzlyAdapterChain supporte maintenant plusieurs adapteurs et peut transformer les requêtes d’entrées à la volée
  • Le framework Comet a amélioré ses performances. À voir aussi un exemple d’implémentation utilisant GrizzlyComet : Writing a Twitter like application using Grizzly Comet part 1: The Servlet.

  Présentation de Google Guice 2.0

  La sortie Guice 2.0 est attendue pour décembre 2008 donc très prochainement.

  À l’image de Spring, Guice est un framework d’injection de dépendances. Cependant, Guice se démarque de Spring dans la mesure où Guice fonctionne sans aucun XML. La configuration et le tissage des dépendances se font de manière programmatique. Il utilise les annotations du langage Java 5.

  Guice se veut être un framework léger et facile à intégrer. Il existe d’ailleurs un plugin Struts pour gérer l’injection de dépendances en Guice.

  L’article Dependency injection with Guice de Nicholas Lesoecki, employé à Google, présente le fonctionnement de Guice.

  Voici le fonctionnement du Guice d’un point de vue programmatique :

  @Inject
  public FrogMan(Vehicle vehicle) {
    this.vehicle = vehicle;
  }
  

  Le tissage s’effectue aussi de manière programmatique, ce qui le différencie radicalement de Spring :

  public class HeroModule implements Module {
    public void configure(Binder binder) {
      binder.bind(Vehicle.class).to(FrogMobile.class);
    }
  }
  

  Le tissage est donc réalisé dans un Module.

  Ensuite le contexte Guice se démarre comme suit :

  public class Adventure {
    public static void main(String[] args){
      Injector injector = Guice.createInjector(new HeroModule());
      FrogMan hero = injector.getInstance(FrogMan.class);
      hero.fightCrime();
    }
  }
  

  Il est possible d’injecter une dépendance par :

  • Constructeur, c’est la méthode la plus simple, par forcément la plus élégante en Spring
  • Méthode
  • Attribut de classe

  Cependant, un problème peut se poser par rapport à l’exemple précédent : comment injecter plusieurs véhicules ? Solution : il faut nommer les cibles en créant ses propres annotations pour l’injection :

  @Inject
  public WeaselGirl(@Fast Vehicle vehicle) {
    this.vehicle = vehicle;
  }
  

  Code source du tissage :

  public class HeroModule implements Module {
   public void configure(Binder binder) {
      binder.bind(Vehicle.class).to(FrogMobile.class);
      binder.bind(Vehicle.class).annotatedWith(Fast.class).to(WeaselCopter.class);
    }
  }
  

  Code source de la déclaration de l’annotation :

  @Retention(RetentionPolicy.RUNTIME)
  @Target({ElementType.FIELD, ElementType.PARAMETER})
  @BindingAnnotation
  public @interface Fast {}
  

  Les nouveautés de cette version sont présentées sur le site officiel : Changes in Guice 2. On y trouve entre autre :

  • Implémentation de l’AOP
  • Surcharge du binding d’un module à un autre
  • Binding des éléments d’un tableau Set ({{Multibinding}}) ou Map ({{Mapbinding}})
  • Convertisseur de type branchable, par exemple, pour convertir une chaîne de caractères en date

  Même si Guice est loin d’avoir la maturité de Spring ou même autant de fonctionnalités que ce dernier, il propose une approche de l’injection de dépendances très pragmatique.

  Une étude sur la comparaison des versions Guice 1.0 et Spring 2.0.2 (Guice vs. Spring JavaConfig: A comparison of DI styles) arrive aux conclusions suivantes :

  • Performance : Guice est plus rapide, mais est-ce vraiment important car généralement les dépendances sont chargées au démarrage de l’application ?
  • Modèle de programmation Guice plus intrusif : il est dommage de devoir mettre un @inject dans les objets Guice qui peuvent être injectés
  • Spring AOP est plus puissante
  • Guice est plus facile à intégrer (il y a seulement 2 Jars à intégrer)

  À voir également : deux liens intéressants sur l’injection de dépendance issus de la documentation de PicoContainer, autre implémentation pour l’injection de dépendance :

  • Design patterns, règles a avoir en tête lorsque l’on fait de l’injection de dépendance
  • Inversion of Control history, tout sur l’injection de dépendance
  ]]> http://blog.xebia.fr/2008/12/15/revue-de-presse-xebia-87/feed/ 4 http://blog.xebia.fr/2008/03/12/gc-generationnels-traditionnels-jdk6-vs-gc-garbage-first-jdk7/ http://blog.xebia.fr/2008/03/12/gc-generationnels-traditionnels-jdk6-vs-gc-garbage-first-jdk7/#comments Wed, 12 Mar 2008 07:28:56 +0000 Erwan Alliaume http://blog.xebia.fr/2008/03/12/gc-generationnels-traditionnels-jdk6-vs-gc-garbage-first-jdk7/ L’analyse empirique montre que dans une application la très grande majorité des objets créés sont détruits presque immédiatement. C’est d’autant plus vrai pour les applications web et/ou stateless où la plupart des objets sont créés pour traiter une requête et peuvent être donc détruits juste après ce traitement. De ce constat résulte l’idée de ne pas traiter de la même façon les objets fraîchement créés et ceux qui existent depuis plus longtemps. Les Garbage Collector qui utilisent des implémentations basées sur ce principe sont appelés GC générationnels. On peut fixer deux catégories d’objectifs lorsque l’on optimise le GC : réduire les pauses ou augmenter le débit. Ces objectifs sont en général orthogonaux (la réduction de la durée des pauses se fait au détriment du débit, et vice-versa), ils dépendent souvent du type d’applications : dans une application interactive, nous privilégierons les pauses, et au contraire, dans un batch, seul le débit compte.

  La suite du billet est décomposée en deux parties :

  • La première décrit le fonctionnement des algorithmes générationnels traditionnels (Implémentation actuelle des JVM Sun)
  • La seconde détaille le nouvel algorithme que Sun essaye de pousser pour sa future JVM

  GC Générationels

  Avant de présenter la nouvelle implémentation que Sun essaye de mettre en avant pour le jdk 7, décrivons le cycle de vie des objets dans le tas (heap) tel qu’il est actuellement implémenté dans les JVM Sun. Le « heap » se compose de trois sections principales « Young », « Tenured » et « Perm ». Au cours de sa vie, un objet est amené à évoluer au sein de ces zones en fonction de son ancienneté, à chaque section correspond une génération d’objet.

  

  Les nouveaux objets sont stockés dans une première zone de la « young generation » appelée « l’eden » (1). Lorsque cette zone est remplie, le garbage collector analyse les objets présents dans cette zone et nettoie les objets devenus inutiles (ne possédant plus de références).

  Les objets ayant résisté à ce passage sont placés dans une seconde partie appelée « survivor » (2). Il s’agit d’une zone intermédiaire contenant les objets les plus vieux de la « young generation ». L’eden ayant été vidée lors du passage du GC, de nouveaux objets peuvent faire leur apparition dans cette même zone. À ce moment deux zones contiennent alors des objets : l’eden et le survivor. Dès lors, lors des futurs passages du GC, ces deux zones seront analysées et les objets toujours en activité seront placés dans une 2e zone « survivor ». Les deux zones « survivors » sont utilisées alternativement par le GC pour stocker les objets utilisés.

  Avant que ces zones ne deviennent également trop petites et lorsqu’un objet est considéré comme assez âgé, il est déplacé dans la deuxième génération : « tenured » (3). Il s’agit d’un emplacement permettant de stocker les objets les plus anciens. Lorsque cette zone est remplie, le garbage collector effectue un nettoyage en profondeur des différentes zones et générations : le full GC. Si après un full GC l’espace disponible n’est pas suffisant pour gérer la vie de l’application, une exception est levée : java.lang.OutOfMemoryException.

  Quant à la troisième section : « la perm », celle-ci stocke les objets n’ayant pas besoin d’être nettoyés par le GC, comme les classes chargées par le class loader lors de l’exécution d’un programme. Ces objets resteront disponibles pendant toute la durée de vie de la JVM. De la même manière, cette zone n’étant jamais nettoyée, si celle-ci vient à saturer, un OutOfMemory est également lancé : « java.lang.OutOfMemoryError: PermGen space » . Son fonctionnement est donc un peu différent : il n’y a pas de promotion dans cette zone.

  Les zones « virtual » ne sont pas utilisées par la machine virtuelle pour stocker des données. Elles correspondent à l’écart entre la taille réelle et la taille max. Leur réservation n’a pas encore été faite auprès système. Elles n’existent que si on a choisi une taille adaptative (Taille Heap Min (-Xms) < Taille Heap Max (-Xmx)).

  

  Pour résumer, les objets sont créés dans « l’eden » (1), puis déplacé dans le « survivor » (2) puis dans le « Tenured » (3).

  Le GC effectue deux types de traitements :

  • Un nettoyage rapide lorsque « l’eden » est rempli, comme il s’agit d’un algorithme de copie, la destruction d’un objet ne coûte rien : zéro inscrution \! Traitement parallélisable.
  • Un nettoyage approfondi, plus gourmand en ressources, lorsque le « tenured est saturé ». Il faut libérer la mémoire explicitement, et éventuellement la compacter (donc déplacer les objets et mettre à jour les références en conséquence) Plusieurs algo disponibles : Mark&Sweep, Concurrent Mark&Sweep, Incremental/train

  L’un des objectifs de l’optimisation du GC est donc de limiter la fréquence des FullGC en s’assurant que le maximum d’objets sera ramassé avant sa promotion dans la old génération. Pour une application web, cela signifie généralement que l’intervalle entre 2 fullGC est supérieur au temps de traitement max d’une requête. Rappelons en passant que la méthode System.gc() déclenche un FullGC et devrait la plupart du temps être proscrite (-XX:+DisableExplicitGC)

  GC Garbage First

  L’idée de l’algorithme G1 (Garbage-First) est d’utiliser les spécificités des environnements multiprocesseurs afin d’approcher des performances ‘temps réel’ tout en maintenant un débit élevé. Pour parvenir à ce but, le tas n’est plus divisé en générations, mais en un nombre beaucoup plus grand de petites régions. Désormais, la collecte d’une génération dans son ensemble n’est maintenant plus obligatoire, elle peut se limiter à un ensemble précis de régions.

  

  La sélection de ces régions est possible grâce à un marquage spécifique : snapshot-at-the-beginning (SATB). Ce marquage, concurrent et très rapide, fournit au GC une analyse périodique et exhaustive de l’utilisation des différents objets en mémoire. Toutes les références des différents objets sont suivies. Leur examen permet la détection des objets qui ne sont plus utilisés : ils sont alors considérés comme déchets.

  Un ensemble de métrique est également maintenu afin de permettre d’évaluer l’occupation des différentes régions du tas : taille maximale de la région, ancienneté, pourcentage d’occupation et surtout, pourcentage de déchets. De plus, les collectes passées permettent au GC de connaître relativement précisément le coût de la collecte d’une région particulière. En croisant ces évaluations (probabilités) avec le recensement des références dans les régions du système, le GC peut effectuer une sélection arbitraire d’un ensemble de régions nettoyable durant une période prédéfinie. La configuration du GC permet à l’utilisateur de spécifier une fraction de temps maximale consacrée à la collecte (par exemple : sur 100 secondes d’exécution de l’application, le nettoyage des données ne peut pas dépasser 5 secondes (5%)), ce qui revient presque à définir les horaires des collectes par configuration. Les régions privilégiées sont celles qui possèdent les données les plus jeunes et le plus de déchets, car elles proposent généralement un meilleur rendement : voici donc d’où vient le nom de l’algorithme « Garbage First ». Cette sélection de régions peut être considérée comme une young génération dont le contenu est défini dynamiquement : Garbage First est donc un algorithme générationnel. Par ailleurs, afin d’éviter de dépasser ce temps ‘objectif’, et donc pour d’optimiser le débit, la collecte peut-être reportée si nécessaire (dans la mesure du possible), peut être qu’au prochain passage plus de déchets seront présents dans une des régions.

  Illustrons ces propos par un exemple :

  Supposons que le tas est découpé en 12 régions. Les zones vertes sur les schémas suivants représentent des régions vides.

  Le marquage a été effectué, il en résulte le découpage suivant. Le pourcentage affiché dans chacune des cases ci-dessous correspond au pourcentage d’objets vivants dans leur région associée. Ainsi dans la 2e case, 3% des objets présents dans celle-ci sont toujours utilisés, par conséquent cette région possède 97% de déchets. Les régions qui ne comptent pas d’objets vivants sont entièrement libérées. La collecte de zone ne contenant que des déchets est très rapide, on peu le comparer à celui utilisé dans les ‘survivor’ dans les algorithmes générationnels traditionnels.

  

  L’application continue de tourner autant de temps que nécessaire pour remplir une nouvelle région intégralement : les nouveaux objets sont référencés dans une même région (case orange). Si un cycle de collection n’est pas suffisant pour remplir cette région, le GC ne se lance pas.

  

  Maintenant que cette nouvelle région est remplie, le GC sélectionne les régions les contenant le plus de déchets qu’il estime pouvoir traiter simultanément (GabageFirst !). Les données vivantes restant dans ces régions sont copiées et rassemblées dans une autre région. Comme il s’agit d’un algorithme de copie, très peu de temps est nécessaire à l’exécution de cette tâche. Une fois que la copie terminée, les zones sélectionnées ne contiennent plus d’objets vivants, elles sont alors collectées.

  

  Au final, si on récapitule, les avantages avancés de ce nouvel algorithme sont les suivants :

  • Meilleure prédiction des temps de pauses destinées au GC.
  • Courte pause sans fragmentation.
  • Nettoyage acceptant la parallélisassions et la concurrence.
  • Meilleure utilisation du tas.

  En plus d’améliorer le débit des collectes, comme le tas n’est pas divisé en générations, les problèmes de sizing des différentes générations ne sont plus d’actualité : fini les prises de tête avec le calcul des ratios young / tenured générations.

  Informations complémentaires à propos de ce nouvel algorithme :

  • Jon Masamitsu’s Weblog : Our Collectors
  • GarbageFirst Garbage Collection (pdf)
  • GarbageFirst : Low Latency, High Throughput Garbage Collection
  
  
  
  ]]> http://blog.xebia.fr/2008/03/12/gc-generationnels-traditionnels-jdk6-vs-gc-garbage-first-jdk7/feed/ 15 http://blog.xebia.fr/2008/02/27/jsr-294-les-superpackages/ http://blog.xebia.fr/2008/02/27/jsr-294-les-superpackages/#comments Wed, 27 Feb 2008 09:06:30 +0000 Erwan Alliaume http://blog.xebia.fr/2008/02/27/jsr-294-les-superpackages/ Lors de la revue de presse du début décembre, nous annoncions le passage en public draft de la JSR-294 (Improved Modularity Support). Cette JSR fait partie de la liste des évolutions potentielles proposées comme amélioration pour le JDK 7. Ce billet fait le point sur ce qu’elle propose.

  Si vous développez en Java depuis plusieurs années, et avez eu l’occasion de travailler sur des bibliothèques réutilisables, vous avez peut-être été confronté au problème suivant : la publication sélective de classes ou de composants. En clair, vous auriez aimé, dans certaines situations, exposer certaines classes d’un package à celles d’un autre package – typiquement dans une relation de type fabriquant-fabriqué que l’on retrouve dans le pattern ‘Factory’. Or Java ne vous propose que 2 options pour exposer une classe : elle peut être publique – donc visible depuis n’importe quel autre package – ou « package private » – c’est-à-dire visible uniquement depuis les classes appartenant au même package. Pour contourner cette gêne, les concepteurs d’API recourent généralement à des stratégies de contournement :

  • Soit ils rendent certaines implémentations internes « publiques », en précisant dans la documentation que leur utilisation n’est pas garantie, et en indiquant les moyens « légaux » de les instancier et de les manipuler. C’est la philosophie adoptée notamment par les auteurs du framework Eclipse.
  • Soit ils simplifient la structure des packages pour regrouper les classes en question. Cette stratégie est plus simple et fiable, mais ne fonctionne pas vraiment avec les API de type SPI (Service Provider Interface), qui ont vocation à être étendues par des tiers.

  La JSR 294 introduit la notion de « superpackage » pour s’attaquer à ce problème. Les superpackages sont destinés à permettre une meilleure organisation interne d’un composant en comblant un trou dans les différentes visibilités fournies par le langage. Il s’agit d’un moyen d’organiser un module lors de la phase de développement. Cette JSR est souvent associée avec la JSR-277 : Java Module System qui propose un nouveau mode de packaging et de déploiement des composants d’un projet. Les superpackages introduisent un nouveau type de visibilité : plus large que ‘default (package)’ mais plus faible que ‘public’.

  Les spécifications de cette JSR sont coécrites par Andreas Sterbenz (membre du « Java SE Security Group » chez Sun) et Alex Buckley (responsable des spécifications du langage (JLS) et de la machine virtuelle java Java VM Specification). Elles sont téléchargeables à cette adresse et sont présentées sous la forme d’une mise à jour des chapitres de la JLS impactés par ces modifications.

  Un superpackage est décrit dans un fichier spécial appelé super-package.java. Celui-ci se décompose en 2 parties distinctes :

  • Une liste de membres (packages, classes ou superpackages) qui le composent.
  • Une liste des membres qu’il rend visibles depuis l’extérieur.

  On peut voir les superpackages comme un regroupement virtuel de classes dont tous les membres bénéficient d’une visibilité mutuelle. La déclaration d’un superpackage se conforme à la syntaxe générale du langage en introduisant 3 nouveaux mots clé :

  • superpackage : un superpackage est une collection d’un ou plusieurs package ou superpackage. Les packages ainsi liés peuvent accéder directement à leurs classes et interfaces ‘public’ respectives. Pour que ces mêmes classes soient accessibles aux packages extérieurs, les types doivent être exportés.
  • member : les membres d’un superpackage sont les packages ou superpackages composant celui-ci.
  export : un type (classe ou interface) est accessible à l’extérieur d’un package s’il est déclaré ‘public’. Un type est accessible à l’extérieur d’un superpackage s’il est déclaré ‘plublic’ ET qu’il est exporté par son superpackage. Les types exportés par un superpackage fils (membre d’une autre superpackage) sont accessibles dans le superpackage père.
  

  Exemple d’utilisation

  Nous désirons mettre à disposition une liste d’interfaces contenues dans le package « fr.xebia.jsr294.sample1″ tout en masquant ses implémentations contenues dans le package « fr.xebia.jsr294.sample1.impl ». Ce dernier nécessite lui aussi des classes contenues dans un autre package « fr.xebia.jsr294.sample1.impl.misc ». En plus de cela, nous voudrions exporter notre classe utilitaire préférée par ce qu’elle est bien codée et qu’en plus on a passé du temps à la tester et que l’on en a envie de montrer notre savoir-faire… Euh, disons plutôt que nous voulons l’exporter à titre d’exemple …

  Le schéma suivant détaille le contenu des différents packages de cet exemple, toutes les classes sont déclarées ‘public’ :

  

  Et voici le contenu des fichiers ‘super-package.java’ :

  Fichier : fr/xebia/jsr294/sample1/super-package.java
  superpackage fr.xebia.jsr294.sample1 {
  	member package fr.xebia.jsr294.sample1;
  	member package fr.xebia.jsr294.sample1.utils;
  	member superpackage fr.xebia.jsr294.sample1.impl;
  	export fr.xebia.jsr294.sample1.utils.MyBeautifulUtils;
  	export package fr.xebia.jsr294.sample1;
  }
  Fichier : fr/xebia/jsr294/sample1/impl/super-package.java
  superpackage fr.xebia.jsr294.sample1.impl member fr.xebia.jsr294.sample1 {
  	member package fr.xebia.jsr294.sample1.impl;
  	member package fr.xebia.jsr294.sample1.impl.misc;
  	export  package fr.xebia.jsr294.sample1.impl;
  }
  

  Quelques remarques

  • Un superpackage père référence ses superpackages fils et inversement. Le père doit maîtriser ses fils pour interdire qu’une classe externe vienne s’ajouter au superpackage.
  • Tout superpackage ne précisant pas de père se retrouve dans un ‘superpackage virtuel’.
  • Toute classe n’appartenant pas à un superpackage est visible dans ce même ‘superpackage virtuel’ (ceux qui ont suivi comprendront que ce ‘superpackage virtuel’ correspond à ce qui existe aujourd’hui).
  • Il est possible d’exporter un sous-ensemble des membres d’un superpackage, dans cet exemple seule la classe fr.xebia.jsr294.sample1.utils.MyBeautifulUtils est exportée alors que tout le package fr.xebia.jsr296.sample1.utils est membre du superpackage.
  • Du fait de l’emplacement des fichiers super-package.java, il ne peut exister qu’une seule définition de superpackage dans un package. Par contre, un package peut-être membre de plusieurs superpackage.

  Comme à l’accoutumée, cette JSR possède son lot de détracteurs. Certains proposent de répondre à ce même problème en retournant la solution : au lieu de masquer ce qui est visible par l’intermédiaire d’une nouvelle boîte construite par un suc syntaxique plus ou moins élégant, il s’agirait d’annoter les classes et méthodes pouvant s’exporter (comme le décrit ce post). D’autres proposent l’ajout d’un nouveau mot-clé pour créer un type de visibilité ‘package et sous-packages’. Toute classe présente dans un sous-package serait visible dans le package père. Il ne s’agit pas du même problème : la version officielle distingue la visibilité (portée par un objet) de la modularité (portée par un système). Pour conclure, je vous laisse découvrir ce commentaire dans lequel l’auteur utilise des ‘static inner-classes’ pour simuler un superpackage.

  ]]> http://blog.xebia.fr/2008/02/27/jsr-294-les-superpackages/feed/ 3 http://blog.xebia.fr/2008/02/20/nagez-avec-les-dauphins-jdk-7-proposals-overview/ http://blog.xebia.fr/2008/02/20/nagez-avec-les-dauphins-jdk-7-proposals-overview/#comments Wed, 20 Feb 2008 08:54:26 +0000 Erwan Alliaume http://blog.xebia.fr/2008/02/20/nagez-avec-les-dauphins-jdk-7-proposals-overview/ Xebia a récemment ouvert ses journées de partage de la connaissance au public (XKE). Ce billet présente l’un des sujets abordés lors de la session de février : les nouveautés du jdk7.

  À l’heure où ces mots sont écrits, il n’existe pas de JSR officielle regroupant les futures fonctionnalités de Java SE 7.0. Il semblerait que Danny Coward y travaille. Il est Chief Architect chez Sun et représentant Sun du Executive Commitee pour le Java Community Process. La JSR officielle devrait voir le jour dans les prochains mois, peut-être avant la prochaine édition de Java One qui aura lieu en mai 2008 à San Francisco. Aucun des points abordés dans cette présentation n’est donc officiel, il ne s’agit que d’une tendance générale.

  Puisque la communauté Java aime les animaux, étudions rapidement l’évolution des noms de codes des différents JDK. Le JDK 5 était représenté par un mammifère carnivore (Tiger) qui annonçait la force et le caractère des nouveautés de celui-ci. La puissance et la rapidité du JDK 6 étaient représentées par un cheval du Nord-Ouest américain (Mustang). Les nouveautés du JDK 7 sont elles représentées par un animal beaucoup plus calme : l’esprit de la mer (Dolphin). Comme les noms de codes s’assagissent à chaque version, et vu que celui du JDK 8 n’est pas encore connu, nous proposons de l’appeler ‘Kitty’, ‘Butterfly’ ou ‘Bunny’.

  Plaisanteries mises à part, la présentation ci-dessous est découpée en 4 parties principales, elle aborde les points suivants :

  • Nouveautés du langage : les sucs syntaxiques et autres modifications du langage
  • Modularité : Superpackage (JSR 294) et Java Module System (JSR 277)
  • Nouvelles API : Nio 2 (JSR 203), Unit and Quantities (JSR 275), Date and Time (JSR 310), Concurrency Utilities Updates (JSR 166y), XQuery (JSR 225), …
  • Nouveautés JVM : Tiered Compilation, new Script engines, G1 garbage collector, …

  
  

  Télécharger en PDF

  
  

  ]]> http://blog.xebia.fr/2008/02/20/nagez-avec-les-dauphins-jdk-7-proposals-overview/feed/ 11