Retours Eclipse Con 2012
Avec 650 participants venant de 36 pays, l’Eclipse Con 2012 qui s’est déroulée à Reston en Virginie, a été encore une fois un succés.
Sur 4 jours, plusieurs dizaines de présentations ont permis de voir les tendances techniques qui s’imposent au fur et à mesure de chaque conférence et notamment :
Eclipse 4
Eclipse 4 va devenir l’architecture RCP officielle à partir de Juin 2012, avec la version Juno (4.2). Néanmoins la version 3.8 sortira également et pourra servir de base pour développer ou faire évoluer une application.
Actuellement en version Juno 4.2M6, cette nouvelle architecture fait l’objet de nombreux débats de couloir ! Beaucoup de personnes l’ont utilisé une fois, peut être trop tôt, et les retours sont plutôt négatifs : ça ne marche pas, c’est compliqué, ça n’apporte rien, c’est pas convaincant… Pourtant, en suivant le tutorial du lundi après-midi, expliquant les différents concepts et invitant à développer une application simple, j’ai pu apprécier l’architecture et les perspectives intéressantes que cette version apportera :
- l’injection de dépendance : elle permet de supprimer tous les accès compliqués des API. Quand on a besoin d’un objet enregistré, il suffit de précéder sa déclaration d’une annotation @Inject. Fini les accès interminables avec des PlatformUI.getWorkbench()….
- le modèle d’application : désormais l’application se décrit dans un modèle entièrement dynamique permettant de définir tous les composants graphiques ainsi que les commandes et handlers. L’éditeur dédié permet d’assembler les différentes vues ou éditeurs (qui sont désormais traités de la même manière). Le contenu graphique des ‘parts’ reste ensuite défini dans le code. Point intéressant également, les parts n’ont plus besoin de dériver de ViewPart ou d’EditorPart. Ce sont des classes simples gérées avec de l’injection.
- La couche de compatibilité : elle permet de faire tourner une application 3.X sur le framework 4.X. D’un usage un peu délicat (il faut bien gérer la launch configuration), cette couche permet d’effectuer une migration progressive. Il faut noter que l’IDE Eclipse 4.2 fonctionne dessus et que la majorité du code de l’IDE n’a pas été réécrit.
On entend alors deux avis : on attend pour voir, et … oui il faut l’utiliser directement.
De toute manière la migration sur cette nouvelle version devra se faire car la plupart des outils commencent à se développer dessus (Xcore, Xtend, etc…)
XText
Autre tendance qui se confirme, la montée de Xtext et de toutes ses implications. Xtext est un framework permettant de décrire un nouveau langage (Domain Specific Language (DSL)), dont l’édition met à jour un modèle en mémoire. L’éditeur ainsi défini à partir d’une grammaire (que l’on peut générer par défaut à partir d’un modèle Ecore), possède automatiquement beaucoup de fonctionnalités difficiles à implémenter à la main, comme : le syntax highlighting, l’auto complétion, la sauvegarde, la recherche, les erreurs de syntaxe, les quickfixes, etc….
Associé au nouveau langage Xtend, la sauvegarde de l’éditeur peut déclencher de la génération de code automatiquement. Ceci permet de décrire à l’aide du DSL dédié une description concentrée d’information qui se génère ensuite dans un langage cible.
Déjà plusieurs utilisations concrètes et opérationnelles de Xtext montrent une nouvelle facette des outils de demain :
- Xcore, l’éditeur textuel de Ecore, permet d’éditer, dans une syntaxe appropriée et simple un modèle Ecore. La sauvegarde du modèle peut déclencher la génération par défaut du code EMF.
- Spray qui propose deux DSL : un pour décrire les shapes et un autre pour les associer aux classes du modèle. Spay génère ensuite directement du code graphiti.
- Xtend, nouveau language simplifiant l’écriture de code (lambda expression, suppression des choses inutiles de java, etc…ah ! et … qui génère du java !
Un DSL avec une sémantique appropriée devient alors beaucoup plus simple à définir et à outiller que d’écrire du code Java dont la sémantique est trop faible ou inappropriée et qui nécessite par conséquent l’écriture de code compliqué.
Xtend 2
Globalement Xtend permet :
- d’utiliser tous les types de java
- de simplifier certains de ses concepts (public implicite, …)
- d’écrire des lambda expressions (accès direct aux sous élements d’une liste par exemple),
- d’écrire des closures (permet d’écrire du code en paramètre d’une méthode, pour définir un listener par exemple).
- de définir des templates à l’intérieur du code (cette partie est issue de « l’ancien » langage de template Xpand défini dans le projet M2T de génération de code
Xtend génère ensuite directement du code java qui est ensuite compilé classiquement.
Ainsi, on peut utiliser Xtend pour développer des classes en utilisant un langage bien plus simple que java, mais aussi pour générer du code en utilisant les fonctionnalités du langage (les templates sont issus de l’ancienne technologie Xpand).
Associé à Xtext (via un builder), Xtend permet ainsi de générer du code à la sauvegarde d’un éditeur Xtext. C’est un peu une nouvelle révolution qui va permettre d’intégrer encore plus fortement les technologies MDA dans le monde du développement. En effet, jusqu’à présent pour faire ce genre de choses, il fallait avoir un éditeur de modèle et lui associer les outils de génération M2T existant (Xpand ou Acceleo). Or ceci était globalement compliqué et nécessitait une expertise avancée qui faisait que ce genre de technologies était finalement peu utilisé dans le monde de l’industrie.
Xtext associé à Xtend devient maintenant une technologie d’intégration des modèles et des générateurs, ce qui offrira une autre opportunité au MDA !
Spray
Un autre outil intéressant commence aussi à apparaître à partir de ces techniques. Il s’agit de Spray, boite à outils pour générer du code graphiti. Les slides de la présentation de karsten sont disponibles ici.
Graphiti est une librairie pour aider à réaliser des éditeur graphiques de modèle, en offrant des accès de plus haut niveau que les API de GEF et d’EMF. Ce projet a été créé devant la complexité affichée de GMF Runtime. Malgré tout, Graphiti nécessite d’écrire plusieurs classes (Features) pour chaque classe du modèle, et cette écriture est similaire pour chaque classe.
Ceci a amené l’équipe de Graphiti à proposer un outil permettant de simplement décrire ce qu’on veut faire comme éditeur de diagramme, à l’aide d’un DSL dédié. Bien évidemment, Spray est développé à l’aide d’XText et il se veut d’être un exemple de référence pour cette cette technologie.
Les fichiers descriptifs de Spray consistent simplement à décrire des shapes, qui sont ensuite associés aux classes du modèle. Tout le code graphiti est généré automatiquement dans le projet à chaque sauvegarde de l’un des fichiers.
J’ai d’ailleurs eu l’occasion de faire une séance de travail avec Karsten et Xavier, pour voir ce que Spray permet de faire.
Alors, on est en version 0.5, donc il ne faut pas s’attendre à avoir tout l’éditeur décrit dans les fichiers Spray, mais c’est un début bien prometteur pour ce produit. Notamment, les propriétés ne sont pas encore toutes générées. Et on peut voir le fonctionnement XText/Xtend qui produit tout le code graphiti à chaud.
Voilà donc pour ce résumé technique de cette conférence. Je ne détaille pas le trajet en A380 (très confortable même en éco) où ça parlait d’ailleurs pas mal d’Eclipse, les 3 j passés a New York avant de rentrer lundi en subissant la grève des contrôleurs aériens français (4h d’attente à Amsterdam…)…
Prochaine conférence : Eclipse Con Europe à Ludwigsburg (au sud de Stuttgart).
