3. Olivier, peux-tu commencer par nous rappeler ce qu'est Eclipse RCP ?
Eclipse RCP, ça veut dire Eclipse Rich Client Platform. C'est un framework de développement qui permet de faire des applications standalone, donc sur poste, à la différence des applications web. Il apporte tout un ensemble de composants qu'on peut directement exploiter dans les applications, que ce soit des vues, des organisations de vues, des éditeurs, des préférences, des choses comme ça. C'est en fait un framework qui permet de développer très rapidement des applications. Contrairement à, par exemple Java Swing, où on aura simplement des widgets et quelques babioles autour, pas forcément standardisées. Donc du coup, chaque personne qui développerait une application en Swing aurait sa propre méthode de développement. Avec Eclipse RCP, il y a des choses qui existent, on les utilise, et les applications RCP se ressemblent un peu toutes. Donc, ça permet d'uniformiser les développements, de gagner du temps, de récupérer également des composants qui ont déjà été développés ailleurs. Voilà pour les grandes lignes. Après sur le plan technique, l'architecture RCP est basée sur une architecture OSGi, donc très modulaire, qui permet d'assembler des composants dans un logiciel de manière très simple. Donc, c'est ça en gros ce qui fait la force d'Eclipse RCP. A ça il faut ajouter que c'est Open Source, que c'est gratuit et il y a également une licence qui est gérée par la fondation Eclipse, qui s'appelle EPL, Eclipse Public Licence, qui permet en gros de faire tout ce que l'on veut avec le code d'Eclipse. On peut très bien, pourquoi pas, revendre tout Eclipse directement, ou récupérer 95% de code Open Source, rajouter du code et changer la licence et faire un produit commercial avec.
4. Tu as évoqué un point important, dans Eclipse RCP, il y a Eclipse.
Et il y a Eclipse bien sûr. Alors Eclipse, ça a plusieurs sens. Eclipse au sens de l'IDE, l'atelier de développement pour faire nos applications. Et puis il y a également la fondation Eclipse qui assure que dans le code des plugins Eclipse que l'on va récupérer, il n'y a pas de code parasite qui pourrait poser problème avec des licences qui ne seraient pas compatibles avec des développements commerciaux. Il y a des juristes à la fondation qui permettent de faire cela. C'est vrai qu'Eclipse RCP, c'est tout un écosystème autour qui permet de faire des développements optimisés.
5. Petit détail : quand on développe avec le SDK Eclipse RCP, le runtime c'est Eclipse.
Alors, c'est pour ça qu'il faut distinguer deux choses. Eclipse RCP, c'est une application riche basée effectivement sur la plate-forme Eclipse. Quand on dit qu'on utilise Eclipse pour développer, on utilise Eclipse IDE, l'atelier de développement, qui est aussi basé sur cette plate-forme. Après il y a le noyau Eclipse derrière qui est basé sur un ensemble de plugins OSGi qu'on assemble en fonction des besoins.
Non, dans Eclipse, il y a une autre librairie graphique qui s'appelle SWT. Ca veut dire Standard Widget Tooling (InfoQ: en fait Standard Widget Toolkit). Il est implémenté sous forme d'interface dans Eclipse qui est fournie avec des implémentations spécifiques à chaque (architecture) machine, ça permet d'utiliser le code natif des librairies graphiques de chaque (architecture) machine, contrairement à Swing où c'est du code Java directement qui est exploité. Donc, en gros, les performances graphiques d'une machine vont être exploitées par une application SWT automatiquement. Autre chose intéressante, SWT a aussi une implémentation qui s'appelle RWT (RAP Widget Toolkit) qui permet de déporter une application graphique écrite en SWT dans un navigateur.
7. D'accord, c'est lié à Eclipse RAP ?
Oui, ça fait partie d'Eclipse RAP. Dans la target platform RAP, dans l'ensemble des plugins qu'on utilise pour faire une application RAP (RAP veut dire Remote Application Plateform depuis la version 2.0), il y a à l'intérieur la version RWT qui permet de déporter l'IHM dans un navigateur, ce qui est intéressant.
8. En effet, avec le même modèle de développement que RCP.
Avec exactement le même modèle de développement qu'Eclipse RCP, les plugins, on récupère exactement tout dans l'application.
En juin 2012, enfin, la 4.0 est sortie en 2010 mais c'était un prototype. La version officielle, c'est la 4.2 de juin 2012.
10. Oui et maintenant, il y a quand même du nouveau, on est plus à l'état de prototype.
Oui, tout à fait, il y a du nouveau, il y a la version 4.3 qui est sortie en juin 2013, cette version va apporter des nouveautés sur l'architecture 4. Depuis Juin 2012, l'architecture 4 est l'architecture officielle pour développer des applications RCP. Il se trouve qu'il y a un écosystème qui existe depuis longtemps. Ca fait 8 ou 10 ans que les gens développent sous Eclipse 3, donc la migration ne va pas se faire en 6 mois. Cette architecture Eclipse 4 apporte des nouveautés qui sont très intéressantes. En fait, elle enlève certains soucis qu'il y avait dans Eclipse 3, de complexité notamment. Donc c'est l'architecture qui est préconisée pour développer de nouvelles applications. Maintenant, la question qui va se poser est pour ceux qui ont développé des applications en Eclipse 3. Qu'est-ce qu'ils vont faire, est-ce qu'ils gardent la souche Eclipse 3 ou est-ce qu'ils passent en Eclipse 4 ? Tout le débat est là aujourd'hui. Parce que certaines choses même dans Eclipse 4 qu'on télécharge aujourd'hui, dans l'IDE, dans l'atelier de développement, il y a des parties qui ne sont pas du tout en Eclipse 4, qui sont encore en Eclipse 3. Donc, tout n'est pas porté, même sous Eclipse, sur cette nouvelle plate-forme.
Voilà, c'est ça. C'est pour ça qu'ils n'ont pas tout porté. Cette couche de compatibilité, elle est magique, elle permet de prendre une application Eclipse 3 et de la faire tourner sur une architecture Eclipse 4.
Voilà, alors il y a des gens qui ont remonté quelques petits soucis mais globalement quand on lance Eclipse 4.2 pour développer en Java, ça a été lancé avec la couche de compatibilité et il y a globalement une majorité de plugins qui sont encore en Eclipse 3 et tournent avec la couche de compatibilité.
Il y a une grosse majorité. Si on pense au JDT, ce sont tous les outils pour faire du Java dans Eclipse. Le JDT n'est pas porté en Eclipse 4 par exemple. Et d'après les interviews que j'ai pu voir là dessus, il ne va pas être porté de suite en Eclipse 4. Parce qu'il y a Java 7 et Java 8 à mettre à jour dans les outils, ils ont d'autres priorités pour le moment. La couche de compatibilité est plutôt bonne. Quand il y a eu Eclipse 3.0, il a fallu faire le portage à la main. Là dans Eclipse 4, la couche de compatibilité cache un petit peu tout ce qu'il faudrait faire, donc c'est bien mais d'un autre coté, les gens se disent que ça pousse pas à une migration automatique. Bon, c'est quand même une bonne approche qui a été faite.
Alors, dans Eclipse 4, ils se sont demandés ce qu'il faudrait apporter dans une architecture comme Eclipse RCP, quelles sont les techniques modernes qui existent aujourd'hui et qui n'existent pas dans Eclipse 3 qu'il faudrait qu'on mette dans cette nouvelle plate-forme. Il y a eu plusieurs choses qui ont été identifiées, notamment ce qui est intéressant dans Eclipse 4, c'est la gestion de l'injection, on peut faire de l'injection dans les classes. Alors, l'injection, ça consiste à récupérer d'un contexte global les valeurs, les instances de classes qu'on veut utiliser. Donc ça supprime beaucoup de problématiques qu'il peut y avoir d'initialisation, ça permet d'avoir du code beaucoup plus modulaire.
15. Ca utilise les annotations standards ?
Alors, ça utilise les annotations standards de deux JSR (JSR 250), plus des annotations spécifiques à Eclipse 4, alors justement, puisqu'on rebondit sur les annotations, il y a aussi des annotations dans Eclipse 4 qui sont des annotations de comportement, qu'il va falloir mettre dans certaines classes. Elles permettent de compenser le fait que maintenant quand on va écrire des classes que l'on va greffer sur l'architecture Eclipse 4, on va écrire que des POJOs, ce sont des objets Java qui ne dérivent de rien. Contrairement à Eclipse 3 où dès qu'on écrivait une perspective, une vue ou n'importe quel objet, il fallait dériver d'une classe d'Eclipse 3. Donc ça c'est une nouveauté dans Eclipse 4 et ça permet de s'affranchir du framework. Tout ça est réuni dans un fichier qui s'appelle l'application model. C'est le modèle d'application qui peut accueillir des POJOs de n'importe quelle (technologie). Ils peuvent être écris en SWT, en JavaFX et éventuellement dans d'autres frameworks. Puisque cet application model est ensuite restitué par un renderer qui tourne dessus et qui permet d'afficher des POJOs directement.
Voilà c'est ça. Exactement. Autant dans Eclipse 3, quand on devait décrire quelque chose, il fallait créer des extensions : faire une extension de vue, une extension de perspective, une extension de menu, etc … Dans Eclipse 4, on va partir de l'application model, qui est hiérarchique, alors que les extensions étaient toutes au même niveau. Alors c'était plus fouillis on va dire, donc dans Eclipse 4, tout est hiérarchique dans le modèle. Si on veut mettre un menu par exemple dans le menu principal, une commande dans le menu principal, vous allez dans le menu principal, dans le 2e menu par exemple, et vous mettez votre commande à cet endroit là. En Eclipse 3 pour faire ça, il faut prendre les points d'extension, il faut écrire ça avec une uri un petit peu spéciale et on voit pas forcément exactement l'endroit où ça va se situer alors que là on le voit directement. Dans Eclipse 4, ils ont hiérarchisé la description de l'application. Ils l'ont beaucoup mieux décrite, donc à partir de modèle et donc à partir d'EMF. C'est à dire qu'il y a un méta modèle de l'application E4 (Eclipse 4) qui est décrit dans la plate-forme E4.
Non, c'est l'avantage de la plate-forme 4, il n'y a pas besoin d'être un expert EMF pour faire une architecture E4. Au contraire, ils ont utilisé la puissance d'EMF pour décrire un méta modèle qui décrit ce qu'on attend dans une application, finalement, c'est assez hiérarchique, il y a un ensemble d'initialisations, il y a ensuite une architecture d'IHM qui est hiérarchique, avec des perspectives, des vues à l'intérieur, etc … Et ça se fait très intuitivement dans un éditeur de modèles. Donc finalement, EMF a été utilisé pour produire ces outils, mais après un utilisateur final ne sait pas que c'est de l'EMF derrière. Ca à la limite, il ne le voit même pas. Et donc, aussi autre intérêt d'avoir utilisé EMF pour cet application model, c'est que cet application model est dynamique, dès qu'on change quelque chose dedans, il y a une restitution directement sur l'écran. Donc, si par exemple, on dit tiens, cette vue, elle n'est plus visible, eh bien la vue va disparaître directement sur l'écran. Donc, ça permet en fait de manipuler directement les objets du modèle de manière uniforme, sans avoir des API compliquées sur chaque objet qu'on veut gérer. Donc, ça c'est très intéressant aussi. Ca simplifie beaucoup de choses.
18. Ok, donc le modèle qui représente la vue est rendu en temps réel.
Oui, il est rendu directement. Dès qu'il y a une modification, il est rendu directement. En fait, l'application model s'arrête aux vues, après le contenu de la vue, c'est le POJO qui va le définir. Il est externe, il est référencé par l'application model et ce POJO, lui va être écrit en JavaFX ou en SWT. C'est un squelette d'application. C'est un peu comme si on ne voyait pas ce qu'il y a dans les vues, si on avait tout grisé, et puis on voyait que les contours des vues, ce qu'il y a sur notre écran.
19. Oui, je vois très bien. Le contenu de la vue, ça va être JavaFX, Swing.
Oui, alors pour Swing, je ne sais pas si le renderer existe mais il pourrait tout à fait. Aujourd'hui, il existe un renderer JavaFX et un renderer SWT.
20. A une époque il avait été évoqué XAML.
Oui, à une époque, ils avaient évoqué XWT, on pourrait décrire les IHMs en XWT.
21. Ce n'est plus d'actualité ?
Alors, ça devait faire partie de la souche E4 et ça a été enlevé, je ne sais pas pourquoi. Le projet existe toujours mais je pense que les gens qui devaient travailler dessus ont du lever le pied, peut-être, je ne sais pas.
22. Tu disais que le renderer JavaFX était déjà disponible ?
Alors, oui, c'est Tom Schindle qui s'occupe de ce projet-là (e(fx)clipse), il fait souvent des demos en JavaFX, donc oui il existe. Il est disponible.
C'est clair que faire une application Eclipse 4, si on part de zéro … il y a certaines choses qui manquent dans Eclipse 4 qui existaient dans Eclipse 3, donc quelqu'un qui connait très bien Eclipse 3 va se dire qu'il manque trop de choses et ne va pas démarrer avec. Moi je trouve que ça ne serait pas forcément une bonne approche parce que Eclipse 4 apporte beaucoup de nouveautés qui sont vraiment puissantes pour les développements. Je les ai utilisées pour plusieurs exemples et c'est vrai qu'on développe plus vite en Eclipse 4. Avec l'injection, une fois qu'on a bien compris tous les mécanismes, et même s'il manque des choses, ce qui manque en fait, c'est simplement un peu de glue code entre JFace, qui est une autre librairie graphique d'Eclipse qui existe dans Eclipse 4, entre JFace et le framework en fait. C'est tout ce qui gère les pages de préférences, tout ce qui gère les pages de properties, les wizards, les dialogues, ça c'est pas encore modélisé dans l'application model mais s'il fallait l'utiliser on pourrait appeler JFace directement. Chose que faisait Eclipse 3 avant. Mais bon, ce n’est pas non plus hyper limitatif.
24. Alors, il y a un point que tu as évoqué rapidement, c'est les CSS.
Alors, oui, l'histoire du renderer, qui rend l'application model, au niveau de l'affichage, effectivement, ça a permis de pouvoir interagir plus facilement sur les IHMs, et il y a possibilité dans Eclipse 4 d'entièrement customiser son application avec des CSS (feuilles de style). Ca c'est très puissant, et c'est très simple à faire. Si par exemple vous avez une application où on veut que tous les libellés aient telle fonte (de caractères), il s'agit d'une ligne dans la CSS, alors que dans Eclipse 3, c'est loin d'être simple à faire.
La CSS s'applique sur les POJOs, je ne sais pas comment c'est câblé derrière au niveau du rendu mais le fait qu'il y a ait un renderer fait que l'on peut le customiser. J'ai vu des démos, notamment à EclipseCON Europe peut-être où ils customisaient la façon dont les vues étaient affichées, par exemple. Avec des onglets carrés, ou ronds, etc. On peut déjà intervenir à ce niveau là et après, la CSS, je ne sais pas comment elle est câblée derrière, mais quoi qu'il en soit, dans la CSS, il suffit de donner le nom de la classe SWT que l'on veut styler, par exemple Label, ou Tree, ou Table, on met derrière les attributs CSS qu'il faut et ça va directement interagir sur les widgets SWT.
Normalement, ça devrait fonctionner. Ca peut être un des avantages de passer à Eclipse 4, c'est à dire se dire, j'ai une application Eclipse 3, je la passe en Eclipse 4 parce que je voudrais bénéficier des CSS. Sinon, il faut que j'aille restyler tous mes widjets à la main dans chaque classe que j'ai écrite. Ca peut être un peu compliqué sauf si on l'avait bien prévu mais bon…
Oui, il y a eu même quelques messages dans les forums assez incendiaires là dessus. "La 4.2 est 6000 fois moins rapide que Indigo", c'était assez tonique au niveau des messages, donc après, la fondation a réagi à ça, ils ont relancé des tests, avec Google je crois, sur tout ce framework là. Personnellement, j'utilise tout le temps la 4.2, la 4.3, enfin Kepler, qui est sortie maintenant, pour les formations. Je n'ai pas vu de ralentissements, personnellement sur la nouvelle version, pour moi, ça marche très bien. Il y a peut être, ça va dépendre ensuite des machines, sur Windows, sur Mac ou sur Linux … Sur Linux par exemple à un moment, ça marchait très mal. J'ai fait des formations sur Linux avec Juno et il y avait des bugs carrément d'affichage, bon bah ça c'est résolu, au fur et à mesure. De toute façon, c'est l'une des priorités, c'est que ça fonctionne bien, comme avant et que ce soit aussi rapide. Même s'il y a la couche de compatibilité qui peut être un peu lourde au début.
C'est marrant parce que ce même débat existait il y a 10 ans dans les années 2000 ou il y avait la bulle internet et on disait "on va tout faire en web". C'était la grosse folie puis après on est revenu en arrière, on disait, "il faut aussi des applis desktop". Dans tous les cas, c'est bien d'avoir les deux finalement. Si on a son word sur son PC et puis qu'on veut travailler dessus et puis qu'on a, si on prend Google Docs, et qu'on fait son document pour le partager avec des gens, c'est bien, on a les deux manières de fonctionner. Donc après, on n'a pas que le standalone sur un poste ou que les applis web. Les deux modes sont intéressants. Avec Eclipse RCP, l'avantage est que si on fait une appli Eclipse RCP. J'avais vu le cas d'une appli Eclipse RCP écrite en SWT qui faisait simplement du rendu de base de données pour naviguer dans des tables, changer des champs, une appli CRUD on va dire, de modification de données. Cette application là, certains de ses écrans avaient été portés grâce à RAP dans un navigateur parce qu'il fallait juste ressortir certains écrans. L'avantage d'RCP, c'est qu'on n'est plus obligé de se prendre la tête à se dire, je fais une appli standalone, je fais une appli web. Si on veut faire une appli web et qu'on a déjà fait une appli standalone, on pourra avoir une sortie sur le web. Maintenant, si on part d'une appli web, pour avoir une appli standalone, ça va être plus compliqué. Maintenant, je pense qu'une appli a vocation à être dans les deux mondes, sans qu'on soit obligé d'écrire deux fois une appli. Se laisser la possibilité de mettre l'appli sur le web, ça peut être intéressant. Souvent l'exemple qu'on donne pour donner la distinction entre appli web, appli standalone, c'est typiquement une appli bancaire. Toi, quand tu vas consulter tes comptes sur la banque, bon, tu as une certaine appli web pour consulter tes comptes puis ton conseiller, il a une autre appli où il peut calculer ses crédits, créer ses dossiers, etc … Et il vaut mieux, même si c'est une appli client/serveur que l'appli soit installée sur son poste. Donc souvent, parce que le faire en web c'est plus compliqué. Une appli web, ça reste quand même compliqué à faire au niveau des technos.
C'est pas la même cible, c'est pas les même développeurs, c'est pas le même métier. Un développeur Java qui a fait que du standalone, si on le met sur des applis web, il va avoir du mal. Donc, c'est deux métiers différents aussi. Que ça s'unifie, c'est bien. Parce que ça commençait à devenir un peu pénible de choisir dès le départ.
31. Au niveau technologique, fonctionnalité, …
Le fait que ça reparte sur une nouvelle plate-forme, Eclipse 4, avec l'injection, l'application model, le fait qu'on se décorrèle complètement d'un framework. On est plus entièrement lié au framework. Le but d'Eclipse 4, c'est que le développement soit plus simple et je pense que l'objectif est déjà atteint. Parce que c'est vrai que c'est plus rapide le développement Eclipse 4 si on part de rien et qu'on s'affranchit du fait qu'il manque encore des choses. Mais ça va arriver. Les choses vont être portées au fur et à mesure. J'avais participé à des BOFs, des réunions le soir après les conférences, à EclipseCON, sur Eclipse 4, et il y a eu pas mal de discussions sur comment gérer les dialogues, gérer les préférences, comment gérer ce genre de choses. Bon bah ça, ils en sont conscients que ça manque et ça va être fait dès que possible mais il faut aussi qu'il y ait les ressources. Il n'y a pas eu non plus je trouve énormément de ressources qui travaillent sur Eclipse 4 par rapport aux versions d'avant. Ca donne cette impression, donc ça prend peut-être un peu plus de temps. Mais tous les outils migrent ou vont migrer vers Eclipse 4. Faut qu'il y ait une masse critique de choses qui soient migrées dans la plate-forme et ça c'est pas le cas encore je pense. C'est pour ça que c'est pas la ruée vers la migration.