Traductions pour la plateforme Java

Réunion du JUG Lyon du 19 avril / Compte-rendu

Encore une fois, les présentations faites lors de la réunion du 19/04 se sont révélées très intéressantes. En plus c'était le second anniversaire du JUG Lyon, et il y avait une distribution de cadeaux:

  • 1 entrée à What's Next
  • 2 licences IntelliJ
  • 2 pass Parley's

On était une bonne cinquantaine, ce qui a beaucoup minimisé mes chances de gagner quoi que ce soit. C'est donc sans surprise que je suis reparti bredouille... Heureusement j'avais auparavant prélevé un écôt substantiel sur le buffet, non mais... Ah oui au fait c'était quoi les talks ? Vous trouverez les sildes des présentations sur le billet du JUG Lyon.

IzPack par Julien Ponge

Il est probable que beaucoup de développeurs, et même pas mal de non développeurs, ont déjà installé une application à l'aide d'IzPack. Par exemple, j'ai récemment installé aTunes par ce biais. Julien avait également présenté son projet chez les Cast Codeurs dans l'épisode 32. L'intérêt est bien sûr de packager l'appli de manière standard, puis de laisser IzPack gérer les spécificités de chaque plateforme. Le processus d'installation se fait par une succession d'écrans qu'il est possible de personnaliser de manière plus ou moins complète selon les besoins.

La dualité avec les gestionnaires de packages est également évoquée. J'ai tendance à visualiser çà ainsi: l'installeur fait un push de l'application vers l'OS, tandis que le gestionnaire de packages fait plutôt un pull. Avec cette idée en tête, on comprend bien qu'au niveau de l'installation des mises à jour d'un logiciel, le gestionnaire de packages est plus adapté que l'installeur. C'est ce que nous confirme Julien, tout en nous donnant la solution utilisée dans Glassfish V3: IzPack pour l'installation initiale, et IPS pour les mises à jour.

Le projet IzPack est en v4, et la v5 est en cours de développement. Il s'agit essentiellement d'une refonte technique, car le projet a déjà 10 ans !

Julien nous livre ensuite sa vision, forcément éclairée, de l'Open Source. J'ai bien aimé sa réflexion finale sur le fait qu'un produit ne peut pas devenir bon simplement parce qu'on le passe en Open Source, il faut que le produit soit déjà bon avant pour que la sauce prenne (pour avoir vécu ce genre de tentative désespérée, c'est vrai !).

RestHub par Sébastien Deleuze et Damien Feugas

Bon là c'était du lourd, et j'ai regretté que cette présentation n'aie pas fait l'objet d'une soirée complète. D'autant que ça a commencé après le buffet, donc tard, et du coup les infos ont défilé trop rapidement pour moi. Heureusement, dans le principe, Resthub est relativement simple.

On part du constat que les RIAs constituent l'avenir dans pas mal de situations. Bon nombre de solutions sont déjà courantes (Flex, SilverLight). Le but est double:

  • Faire des IHM plus sympathiques et réactives que la succession habituelle d'écran avec des JSPs
  • Déporter un maximum de choses sur le client, donc le navigateur, permet de réaliser des économies en termes de traitement serveur. Une problématique intéressante dans le cas de grosses applis et dans un contexte green IT à mon avis.

A partir de là, ils ont rassemblé des choses bien connues (en tous cas côté serveur) et qui marchent bien ensemble pour créer uns pile serveur et une pile client:

  • Côté serveur: Spring, Hibernate, JAX-RS plus quelques projets destinés à faciliter la vie des développeurs (Hades, H2)
  • Côté client: des standards comme HTML 5 (vous ne connaissez pas bien ? Il n'est pas trop tard pour commencer à lire la série que je traduis !), et un peu d'innovation maison en piochant les bonnes idées de différents frameworks Javascript existants. C'est surtout cette partie là qui m'intéresse car je pense comme Damien et Sébastien que bientôt (et même déjà) les bons développeurs Java devront savoir produire du bon code JS. Le but est de reproduire côté client des choses que l'on connait bien côté serveur: le MVC, et de considérer le serveur comme un simpe fournisseur de données.

On note au passage que les deux piles sont indépendantes. On peut donc utiliser la pile JS sur n'importe quelle plateforme REST, Java ou pas. C'est aussi intéressant dans une optique de développement où on peut créer simplement des bouchons JSON sur les URLs REST pour les tests.

Bon j'avoue que j'aime beaucoup cette approche, c'est dit ! Et çà pourrait donner lieu à un épisode des Cast Codeurs plutôt sympa, non ?