Revue de Presse Xebia

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

Actualité éditeurs / SSII

• Sortie de la version 1.8 de Groovy

RIA

• Flex 4.5 SDK, Flash Builder 4.5 et Flash Catalyst CS 5.5 enfin disponibles

Le coin de la technique

• Gavin King persiste et signe… 9 billets sur Ceylon

Actualité éditeurs / SSII

Sortie de la version 1.8 de Groovy

Guillaume Laforge, le chef de projet de Groovy, vient d’annoncer sur son blog la sortie de la version 1.8 du célèbre langage de scripting pour la JVM.

Le millésime semble de qualité avec de nombreuses fonctionnalités nouvelles et améliorations – certaines fonctionnalités très populaires ont d’ailleurs été backportées sur la version 1.7. A noter également que, comme le signale Burt Beckwith sur son blog, Grails 1.4 a été mis à jour pour supporter cette nouvelle version.

Nous vous proposons ici un bref aperçu des principales nouveautés; les exemples sont tirés ou inspirés des notes de version, très complètes. Signalons encore une série d’articles publiés très récemment par Mr. Haki sur son blog et qui donnent une description encore plus détaillée de certaines nouveautés de Groovy 1.8.

Support de JSON

De même que pour l’XML, Groovy supporte désormais nativement le langage JSON. Il est ainsi possible, grâce à la classe JsonSlurper, de parser un contenu JSON, de même qu’il est possible d’écrire du code JSON grâce à la classe JsonBuilder:

import groovy.json.*

def json = new JsonBuilder()

json.person {
    name "Guillaume"
    age 33
    pets "Hector", "Felix"
}

println json.toString()

Ce code produit en effet la sortie JSON suivante:

{"person":{"name":"Guillaume","age":33,"pets":["Hector","Felix"]}}

Processus de compilation et transformations de l’Arbre Syntaxique Abstrait

Tout d’abord, une nouveauté prometteuse nous est offerte sous la forme des compilation optimizers: ces « optimiseurs de compilation » permettent de modifier – de façon globale – le comportement du compilateur Groovy; plus précisement, il est possible d’agir sur les niveaux suivants:

1. ImportCustomizer: ajouter des imports « par défaut »;
2. SecureASTCustomizer: filtrage par classe afin d’autoriser ou de prohiber l’utilisation de certaines classes, ce qui permet de sécuriser le code à compiler;
3. ASTTransformationCustomizer: appliquer des transformations AST sur toutes les classes à compiler.

D’autre part, de nouvelles transformations de l’AST sont disponbiles. En voici quelques-unes:

• Il est possible d’injecter un logger dans une classe grâce aux annotations @Log (pour java.util.logging), @Commons (pour commons-logging, @Log4j (pour Log4J) et @Slf4j (pour SLF4J).
• Les annotations @ToString et @EqualsAndHashCode permettent de générer facilement des implémentations de toString(), equals() et hashCode().
• L’annotation @AutoClone permet quant à elle de générer une redéfinition de la méthode clone() et de rendre la classe annotée Cloneable. Différentes stratégies d’implémentation sont possibles: appel de super.clone(), clonage des propriétés de l’objet, appel d’un constructeur par copie, ou encore sérialisation (si l’objet implémente Serializable).
• Les annotations @ThreadInterrupt, @TimedInterrupt et @ConditionalInterrupt permettent respectivement de vérifier qu’un thread a été interrompu, d’interrompre un thread au bout d’un laps de temps et de l’interrompre sous condition.
• Les annotations @WithReadLock et @WithWriteLock permettent de gérer l’accès à une ressource partagée avec une granularité plus fine que celle proposée par la transformation @Synchronized, en utilisant un moniteur de type java.util.concurrent.locks.ReentrantReadWriteLock.

Des descriptions plus détaillées de ces nouvelles transformations sont disponibles ici et ici.

APIs pour la programmation concurrente

Groovy est désormais packagé avec GPars, une puissante et flexible librairie – elle-même en Groovy – proposant de nombreuses APIs pour l’exécution concurrente, asynchrone et/ou distribuée de tâches écrites en Java ou en Groovy. Tous les patterns les plus connus, du Fork/Join au Map/Reduce en passant par les Agents et Actors, sont désormais à la disposition du développeur Groovy.

Ecriture de langages dédiés

L’écriture de langages dédiés ou DSLs (Domain Specific Languages) avec Groovy gagnera en lisibilité grâce à la possibilité de supprimer les parenthèses et les points lors d’un chaînage d’appels de méthodes. Il devient possible d’écrire dans un style fluide très proche du langage naturel; l’exemple suivant est particulièrement frappant:

show = { println it }
square_root = { Math.sqrt(it) }

def please(action) {
  [the: { what ->
    [of: { n -> action(what(n)) }]
  }]
}

//version allégée
please show the square_root of 100

//version classique
please(show).the(square_root).of(100)

Dans un autre post, Guillaume Laforge s’offre même le luxe de concocter une recette de cuisine plutôt lisible:

Recipe.instructions {
   take medium_bowl
   combine soy_sauce, vinegar, chili_powder, garlic
   place chicken into sauce
   turn once to coat
   marinate 30.minutes at room_temperature
}

Closures

Rien de révolutionnaire, mais quelques améliorations notables:

• Il est désormais possible de spécifier des closures comme arguments d’annotations. Ceci ouvre des perpectives intéressantes notamment dans le cadre d’une programmation par contrat, qui pourrait tirer parti de cette nouvelle fonctionnalité pour spécifier sous forme d’annotations des invariants de classe, des pré et post-conditions, etc. Ce genre d’artifice ressemblerait à ceci:

//invariant
@Retention(RetentionPolicy.RUNTIME)
@interface Invariant {
    Class value() // stocke la closure
}

//utilisation de l'invariant
@Invariant({ number >= 0 })
class Distance {
    float number
    String unit
}

L’annotation @Invariant, définie par l’utilisateur, utilise une closure pour spécifier de façon élégante et concise un invariant de classe.

Lorsqu’il s’agit de vérifier l’invariant, cependant, on peut regretter que le code ne soit pas tout aussi trivial, en raison – apparemment – de problèmes de compatibilité:

def d = new Distance(number: 10, unit: "meters")
def anno = Distance.getAnnotation(Invariant)
def check = anno.value().newInstance(d, d)
assert check(d)

• Les nouveaux opérateurs >> et << permettent d’alléger l’écriture des closures composées:

def plus2  = { it + 2 }
def fois3 = { it <strong> 3 }

//version longue
fois3plus2 = { x -> plus2(fois3(x)) }

//version courte
fois3plus2 = plus2 << fois3

• L’utilisation du trampolining » >trampolining permet d’éviter les dépassements de pile (stack overflows) en transformant la récursion terminale de certains algorithmes en code itératif. Alors que le code suivant produit un dépassement de pile à l’exécution:

​def factorial
factorial = { int n, BigInteger accu = 1G ->
    if (n < 2) return accu
    factorial(n - 1, n </strong> accu)
}
println factorial(1000) ​//java.lang.StackOverflowError
​

La version « en trampoline » du même algorithme s’exécute sans problème:

def factorial
factorial = { int n, BigInteger accu = 1G ->
    if (n < 2) return accu
    factorial.trampoline(n - 1, n * accu)
}
factorial = factorial.trampoline()
println factorial(1000)

Grâce à l’appel de la méthode trampoline() qui enveloppe les appels récursifs dans des wrappers de type TrampolineClosure, tant que le « trampoline » appelant reçoit en retour des instances de TrampolineClosure, il continue d’invoquer itérativement la fonction sous-jacente, ne s’arrêtant que lorsque l’objet de retour n’est plus un trampoline. La pile d’appels ne grossit donc pas de façon incontrôlée.

• Le support de la mémoization permet désormais aux closures effectuant de lourds calculs de mettre en cache le résultat des appels en fonction des arguments en entrée.

• La curryfication est désormais possible aussi en partant de la droite, voire même en désignant de façon arbitraire un argument par sa position dans la liste d’arguments.

Autres sucres syntaxiques

• Support du diamond operator de Java 7:

List<List<String>> list1 = new ArrayList<>()

• Nouvelles méthodes DGM (Default Groovy Methods), toujours pratiques, par exemple countBy qui, dans l’exemple suivant, compte le nombre d’occurrences de nombres pairs et impairs dans une liste d’entiers:

assert [0:2, 1:3] == [1,2,3,4,5].countBy{ it % 2 }

• Les slashy strings sont désormais multilignes:

def poem = /
to be
or
not to be
/

• Une nouvelle variante des slashy strings appelée dollar slashy string permet de définir une GString multiligne dans laquelle il n’est pas nécessaire d’échapper le backslash; pratique pour noter du XML ou bien des chemins de fichiers Windows:

def dir = $/C:temp/$

Performances

Enfin, il faut noter que la version 1.8 de Groovy inaugure des chantiers sur les performances du langage. Avec deux améliorations profitables :

• Sur les opérations basiques sur les entiers (additions, soustractions, multiplications, divisions, incréments, décréments et comparaisons). Il faut cependant se rappeler que les optimisations de cette version ne s’appliquent que sur des opérations d’un type unique. Si vous mixez, par exemple, additions et soustractions dans une même ligne de code, vous n’en profiterez pas.

• Sur les appels de méthodes directs. Si un appel de méthode est lancé sur this et que le prototype correspond à une méthode présente (aux types près), Groovy passera outre ses mécanismes de réfléxion standard. Là aussi, faites bien attention aux restrictions pour en tirer parti.

Cela peut paraître maigre mais ce n’est que le début de plus gros chantiers de performances qui auront lieu au cours de la vie de la branche 1.8. Peut-être la fin de la politique « fast enough » de Groovy ?

RIA

Flex 4.5 SDK, Flash Builder 4.5 et Flash Catalyst CS 5.5 enfin disponibles

Bonne nouvelle pour la communauté Flex: aujourd’hui, sort officiellement Flex 4.5 SDK , Flash Builder 4.5 et Flash Catalyst CS 5.5. Après quelques mois en pré-release, disponible en téléchargement privé, la team Flex a profité des retours des utilisateurs qui ont testé les produits. Plus axées sur le développement mobile, ces nouvelles versions permettent de développer des applications riches autant pour le web que pour le desktop ou pour d’autres supports comme les mobiles et les tablettes.

Dans cette nouvelle version de Flash Builder, seul le déploiement sur Android est prévu. Mais une nouvelle version disponible en juin vous permettra de déployer vos applications sur iOS et Blackberry Tablet OS. Parmi les autres nouveautés : un Flash Builder permettant de développer plus rapidement et un workflow amélioré entre Flash Builder et Flash Catalyst : vous pourrez maintenant passer du premier au second sans difficulté pour retravailler le design.

Le coin de la technique

Gavin King persiste et signe… 9 billets sur Ceylon

Il y a à peine deux semaines on évoquait ici-même la présentation qu’avait faite Gavin King du nouveau langage Ceylon, et de l’accueil plutôt mitigé que la communauté lui avait réservé.

Sans doute piqué au vif, Gavin King a publié cette semaine une série de neuf articles (d’autres sont peut-être encore à venir) où il présente le langage avec beaucoup plus de détails et de finesse.

A travers notamment les commentaires des lecteurs, on remarque au fil des billets un certain regain d’intérêt pour ce langage, au fur et à mesure que les contours s’en précisent et que certaines questions trouvent leur réponse. Malgré tout, le langage semble encore souffrir d’un caractère quelque peu confidentiel, et les échanges tournent parfois au débat d’experts. Il faut également noter que la volonté affichée de réécrire un SDK complet pour Ceylon semble laisser certains observateurs sceptiques.

Sans revenir sur les caractéristiques du langage lui-même – nous laissons à nos lecteurs le soin de parcourir ces billets – nous avons concocté un résumé des échanges entre Gavin et ses lecteurs sous la forme de questions-réponses:

Qui travaille dans le projet Ceylon?

S’il admet être le seul à y travailler à temps complet, Gavin révèle tout de même que l’équipe Ceylon compte parmi ses membres quelques blogueurs de In Relation To, parmi lesquels Emmanuel Bernard, Aleš Justin, Jason Greene, Max Handersen et Pete Muir – nous sommes donc bien dans la mouvance Hibernate – Red Hat – JBoss. Toujours d’après Gavin, certains membres de l’équipe OpenJDK (Andrew Haley et Gary Benson) y travailleraient aussi, et enfin, quelques personnes de chez Red Hat (Andrew Dinn, David LLoyd et surtout Mark Little).

Quel est l’état d’avancement du projet?

Gavin admet que l’écriture du parseur ANTLR ne fut pas une partie de plaisir et lui a demandé des mois de travail; cependant, le parsing et la génération de l’AST sont d’après lui terminés et il travaille désormais sur le compilateur: le typechecker est en bon état d’avancement, mais la génération du bytecode aurait pris du retard.

Quel degré d’interopérabilité avec Java?

Il y aura une certaine interopérabilité, mais celle-ci sera mise à mal en raison de l’inexistence de wildcard types et de surcharge de méthodes en Ceylon. Concernant la surcharge, Gavin envisage d’utiliser le principe des GADT (Generalized Algebraic Data Types), inspirés d’Haskell, pour « unifier » les surcharges de méthodes.

Mais plutôt que parler de portage de frameworks Java en Ceylon, Gavin préfère tabler sur l’apparition spontanée de nouveaux frameworks en Ceylon qui viendraient remplacer les frameworks Java à la mode. L’ambition de Ceylon à cet égard semble en effet un point marquant du nouveau langage. Gavin est formel: « nous avons comme but explicite de créer un nouveau SDK (et par là nous entendons vraiment une série de modules que nous allons écrire nous-mêmes) ».

Et Gavin de lister les modules sur lesquels il souhaite se concentrer dans l’immédiat:

• ceylon.language – types de base pour le support des fonctionnalités inhérentes au langage
• ceylon.module – le runtime assurant la modularité (basé sur JBoss Modules)
• ceylon.collection – le framework de collections (l’implémentation sous-jacente serait fournie par le framework Java équivalent)
• ceylon.datetime – support des dates et heures (probablement basé sur la JSR-310)
• ceylon.security – API sécurité
• ceylon.io – Utilitaires d’entrée-sortie (implémentés en utilisant java.io)
• ceylon.concurrent – API pour la programmation concurrente « de bas niveau » (basée sur JSR-166)
• ceylon.http – client et serveur HTTP (peut-être fondé sur Netty)
• ceylon.html – le « Kit de construction » HTML

Par ailleurs, Gavin précise que le compilateur Ceylon est conçu pour s’intégrer avec OpenJDK et pour pouvoir compiler simultanément du code Java et du code Ceylon. Cependant la version initiale (alpha) du compilateur ne contiendra que les modules du langage lui-même.

La modularité

Gavin confirme que la notion de module – une sorte de « super package » avec ses propres portées de visibilité – sera bâtie au sein du langage. Mais il ne s’arrête pas là: il envisage également une entité plus large encore que le module, qu’il baptise assembly. Ceci porte à trois le nombre de niveaux de modularité:

1. package
2. module, matérialisé notamment par une archive dans un format précis, éventuellement déployable sur un dépôt de modules
3. assembly: agrégation de différents modules

Le compilateur ne produirait d’ailleurs pas de fichiers « .class », mais plutôt des archives déployables sur un dépôt local ou distant. De même, il saurait retrouver des dépendances requises depuis ces dépôts.

Quant au runtime, il s’agirait bien de JBoss Modules. Celui-ci saurait gérer les archives et les problématiques de class loading et aussi rechercher et exécuter les modules définis dans sa configuration.