Revue de Presse Xebia

La revue de presse hebdomadaire des écosystèmes Java/JEE proposée par Xebia.

Actualité éditeurs / SSII

• Sortie de Play 2.0 (Par David Galichet)
• Akka 2.0 + Playframework 2.0 = Typesafe Stack 2.0 (Par David Galichet)

Le coin de la technique

• Les risques d’utiliser le shell depuis un programme (Par Jean Helou)
• Chronozoom, un outil de timeline html5 open source (Par Jean Helou)
• Les points clés de JEE 7 (Par Xavier Bucchiotty)
• Combats d’IDE (Par Xavier Bucchiotty)

Actualité éditeurs / SSII

Sortie de Play 2.0

Play 2.0 est un framework web full-stack, léger et orienté haute productivité, permettant de développer des applications en Java ou en Scala. La version 2.0 finale, sortie la semaine dernière est une réécriture complète de la version 1.x passant d’une implémentation en Java à Scala. Cette nouvelle version se veut plus légère, performante et plus simple à maintenir et à faire évoluer que la version 1.x. La philosophie de Playframework 1.x était de s’inspirer des bonnes pratiques rencontrées dans les frameworks web léger (RoR, Razor …), et de faire table rase des technologies devenues standard du web (Java) mais généralement lourdes et vieillissantes (comme par exemple les Servlets pour ne citer qu’elles). Ce travail à continué dans la version 2.0 en corrigeant au passage les erreurs de jeunesse. Ce que propose cette nouvelle version :

• possibilité d’écrire vos applications en Scala ou en Java,
• un nouveau système de templating particulièrement intéressant puisque les templates sont maintenant compilés. Vous êtes ainsi prévenus par le compilateur dans le cas où vous ne passeriez pas les bonnes données à votre template (avec ce système, le refactoring devient un vrai bonheur ! ),
• le fichier de description des routes (url mapping) est lui aussi compilé,
• le système de build incrémental (rechargement à chaud des modifications en mode développement) repose maintenant sur l’outil SBT. Ce nouveau système de build permet d’augmenter plus facilement le framework à l’aide de plugins,
• le framework est sans état (comme en version 1.x) et repose sur les données stockées dans un cookie pour conserver des données de session. Ce principe simplifie la scalabilité horizontale puisqu’il n’y a pas besoin de mécanisme d’affinité ou de réplication de session,
• le framework repose sur Akka 2.0 sorti la semaine dernière ce qui vous permet d’utiliser out of the box des acteurs,
• le framework est léger. Au démarrage, une application Play 2.0 possède une Heap pesant entre 2 et 3Mo, et ne variera que peu tant que votre application ne garde pas d’état volumineux en mémoire (cela peut devenir le cas si par exemple vous utilisez un grand nombre d’acteurs),
• le framework est performant. Il repose sur une architecture non bloquante (utilisant netty) et permet d’absorber des charges importantes,
• Play 2.0 supporte les websockets, permettant des communications full-duplex et asynchrones entre le navigateur et le serveur,
• un système d’accès aux base de données relationnelles nommé Anorm avec lequel le SQL est remis en avant et qui utilise les capacités de parsing de Scala pour extraire les données du ResultSet et créer les objets. Cette approche est totalement différente des classiques ORM style Hibernate. On aime ou on aime pas (personnellement, je suis plutôt fan d’Anorm),
• en version 1.x, le bytecode était modifié par le framework pour ajouter des fonctionnalités ce qui impliquaient que certains comportements pouvaient apparaître un peu auto-magique. Ce n’est plus le cas de la version 2.0 qui s’appuie sur les possibilités offertes par Scala et de la programmation fonctionnelle, ce qui donne une meilleure compréhension du framework (si tant est que l’on ai un quelques connaissances en Scala). L’approche est aussi beaucoup plus type safe ce qui permet de voir beaucoup plus d’erreurs au moment de la compilation plutôt qu’au runtime.

Cette liste n’est bien entendu pas exhaustive des fonctionnalités du framework. Pour finir ce tour d’horizon de Play 2.0, il est important de signaler que la communauté autour de ce framework est réellement importante et que les core développeurs sont particulièrement réactif sur la résolution des problèmes.

Akka 2.0 + Playframework 2.0 = Typesafe Stack 2.0

Dans notre dernière revue de presse, nous vous parlions de la sortie de Akka 2.0. Cette dernière version vient tout juste d’être intégré dans la version 2.0 de la stack Typesafe avec Play 2.0 (dont nous venons tout juste de vous parler) et un nouveau produit appelé Typesafe Console. Cette stack est aussi composée d’un plugin Eclipse pour le développement Scala et de l’outil de build Simple Build Tool.

Outre Akka 2.0 et Play 2.0, la grande nouveauté de cette Stack estampillée 2.0 est l’apparition d’une console permettant d’obtenir de monitorer les applications construites autour de la Stack Typesafe. Disons le tout de suite, la console est tout simplement bluffante (vous pouvez vous en rendre compte grâce à cette démo). Elle permet d’obtenir une vue sur l’état de votre système (consommation CPU, mémoire, réseau …), et notamment sur les acteurs Akka (liste des acteurs, messages en attente, temps d’attente, nombre de messages traités, erreurs …). Cette console développée avec Play2.0 et Akka2.0 sera malheureusement réservée aux souscripteurs de l’offre commerciale de Typesafe.

Cette nouvelle version de la Stack Typesafe apporte donc un grand nombre de nouveautés ainsi qu’un horizon beaucoup plus large, notamment grâce à l’arrivé de Play2.0, un framework haute performance, haute productivité et particulièrement simple d’utilisation, mettant Scala à la porté d’un nombre potentiellement accru d’utilisateurs.

Le coin de la technique

Les risques d’utiliser le shell depuis un programme

Les auteurs du langage de programmation julia proposent un article très complet sur les raisons qui font que l’appel au shell pour exécuter des commandes depuis un programme est souvent dangereux, fragile et peu sûr. A travers des exemples en ruby ils démontrent :

• la fragilité des métacaractères : la construction de la chaîne de commande par programme mène presque toujours à du code fragile notamment la gestion des caractères spéciaux et des espaces; chaque programme les gère à sa façon.
• l’inefficacité et la perte d’information de l’indirection : utiliser le shell pour exécuter d’autres programmes, en particulier des chaînes de programme peut aisément mener à des pertes d’informations, typiquement à la perte du résultat d’exécution des commandes. Quant au niveau d’indirection créé, il n’est pas gratuit, le shell va lire ses fichiers de configuration et consommer lui-même des ressources, diminuant l’efficacité du traitement.
• Les erreurs sont silencieuses par défaut: la plupart des langages de programmation considèrent qu’une erreur d’exécution du shell n’est pas une erreur dans le programme. Les programmeurs doivent manuellement vérifier le code de retour du shell pour savoir si l’exécution s’est bien passée et même comme ça le résultat peut parfois être faux.

L’auteur fait un résumé précis des problèmes qui peuvent être rencontrés, de la façon de les gérer dans la plupart des langages. Il démontre que le code qu’il faut écrire est souvent bien loin du code idiomatique du langage de programmation. Il mentionne brièvement python qui offre une façon d’exécuter des chaînes de commandes sans passer par un shell mais ne mentionne pas encore la méthode que le langage julia utilisera pour éviter ces chausse-trappes.

Ajoutons également un autre point bloquant : la sortie standard et la sortie d’erreur des processus ainsi lancés doivent être gérées au niveau du programme appelant. L’excellent livre « Java Puzzlers » de Joshua Bloch et Neal Gafter nous rappelle ainsi, au Puzzle 82 « Beer Blast », que si nous ne gérons pas ces deux sorties, nous risquons un blocage pur et simple de nos applications, même si la commande exécutée est tout à fait correcte.

Chronozoom, un outil de timeline html5 open source

Le professeur Walter Alvarez de l’université de Berkeley en Californie, célèbre pour avoir proposé la théorie de l’impact d’astéroid pour expliquer l’extinction des dinosaures a développé, en collaboration avec Microsoft Research, un outil de représentation interactive de timeline en HTML5 s’appuyant sur des services Azure, nommé Chronozoom.
L’outil est open source et son code source est disponible et hébergé sur codeplex.

La timeline présentée en exemple est celle de la vie de l’univers, l’outil permettant de zoomer ou de prendre du recul jusqu’à une précision d’une journée de façon assez fluide quand on considère la quantité de contenu présenté et intégré dans la page. Au fur et à mesure que l’utilisateur zoom, des contenus multimédia sont intégrés.

Les points clés de JEE 7

La sortie de Java EE 7 est annoncée pour le second semestre 2012. Nous vous conseillons ce billet qui synthétise les points clés de cette nouvelle spécification.
On retrouve tous les sujets brûlants actuels et à venir.
Nous avons des sujets Web:

• La gestion des liens hypermedia avec JAX-RS 2.0, pour avoir plus facilement des services qui respectent le principe de connexion dans les Services-Web REST.
• L’intégration d’une API JSON avec la JSR-353.

De l’architecture distribuée et élastique

• Une standardisation des technologies de cache in-memory distribués sur plusieurs JVM avec la JSR-107
• L’arrivée d’architecture NIO ou encore l’implémentation des WebSockets HTML5 avec la JSR-340
• L’apport de la notion de QualityofService avec les API du package javax.state et la JSR-350
• Une meilleure intégration au environnement cloud type PaaS à l’aide de description de meta-données avec notamment la JSR-342

Le tout sera embarqué dans les serveurs respectants cette future norme, à commencer par Glassfish.

Combats d’IDE

Il y a forcément un développeur dans votre open-space qui n’utilise jamais le même IDE que les autres. Les querelles entre utilisateurs d’Eclipse et d’Intellij IDEA existent donc un peu partout dans le monde. Entre les pro open-source, les pro-100%clavier… chacun possède son avis et ses habitudes.

Sur le site dzone.com a été relayé le billet d’un amateur d’Intellij. Le point de vue de l’auteur,Andrei Solntsev, est pour le moins intéressant. Il a développé pendant cinq ans pour Eclipse, avec l’écriture de nombreux plugins à son actif!
Il affirme haut et fort sa préférence pour IntelliJ comme IDE JAVA en l’expliquant clairement. Pour lui, c’est simple, les actions dans Intellij sont beaucoup plus sensibles au contexte qu’Eclipse. Il n’est pas nécessaire de sélectionner du code pour faire du refactoring. Placer le curseur sur la ligne suffit, Intellij en déduit ce que vous voulez faire et ne vous demande une intervention que pour lever les ambiguïtés.
Cela fonctionne pour la sélection d’expression à évaluer en mode « debug », l’auto-completion et surtout le refactoring.

Que vous choisissiez l’un ou l’autre, le mieux est toujours de savoir se servir correctement de ses outils. Ce qui compte avant tout, c’est la qualité du code écrit (et un peu la peine relative que vous avez eu pour le faire !). C’est d’ailleurs l’un des sujets de nos journées de partage chez Xebia, nos chers XKE!