Je voulais le faire depuis le premier JUG Clermontois, à savoir celui du mois d’octobre 2011, mais je n’ai pas trouvé le temps de m’en occuper avant. C’est donc avec un plaisir immense que j’ai l’honneur de vous partager ce scoop : Ca y’est ! Clermont-Ferrand est enfin dotée de son propre JUG ! Cela me fait un très grand plaisir de voir fleurir à Clermont au moins une conférence orientée sur le langage Java tous les deux mois.

Pour cette première session, ce n’est autre qu’Alexis Moussine Pouchkine (@alexismp sur twitter) qui est venu nous faire l’honneur de sa visite. Cela se passait en octobre 2011. Alexis Moussine Pouchkine, bien connu des utilisateurs de GlassFish, puisqu’en étant l’ambassadeur, nous a présenté les nouveautés de Java 7.

• La gestion du système de fichiers a été grandement améliorée. Voir à ce sujet les JSR 334, 203,166, 292… Ainsi, les classes Path, FileSystem (FAT, ZFS, Zip, NetWork, …) Files (.copy, .standardCopy, .createTempFile, …) PosixFileAttributes, WatchService (système d’écouteur sur un répertoire, un contenu Jar, Zip, …) fournissent un support très avancé de la gestion des fichiers.
• Peu de changements au niveau Swing par contre, si ce n’est de nouveaux look and feels. Pour une gestion plus avancée des composants graphiques, nous nous intéresserons à la nouvelle version de JavaFX (2.0) qui fournit un jeu de composants intégrables dans des interfaces graphiques lourdes. Les méthodes de développements pour Java ME, Java SE, Java FX vont progressivement converger.
• Ensuite, Alexis nous explique également qu’Apple est maintenant membre du JCP ; cela va faciliter l’intégration de Java sur les plateformes Mac. Une update importante de la JDK 7 (update 6, prévue le 28/07/2012) va marquer une étape importante dans le développement de Java et est à prévoir pour l’été 2012.
• Quelques mots pour Java 8 ont également été prononcés ; une première version est attendue pour l’été 2013. Cette nouvelle version améliorera le packaging des applications (cf. JSR 293 sur JigSaw). La communauté Java Coin prévoit également d’intégrer les clojures (JSR335). L’utilisation des options de la JVM sera simplifiée (gestion de la mémoire), Java FX 3.0 confirmera la convergence des méthodes de développement graphiques, de la gestion des périphériques améliorée, etc.

Toujours sur cette première session LavaJUG (http://www.lavajug.org), nous avons également eu l’intervention de Julien Ponge (@jponge sur twitter) qui nous a aussi parlé des nouveautés présentes dans java 7.

• Il parle dans un premier temps du multi-threading, qui a bien évolué, notamment en ce qui concerne le développement parallèle qui est maintenant bien géré par java 7. Bien penser à utiliser un thread pour charger les données en mémoire, puis à utiliser n threads pour maximiser l’utilisation des coeurs (“diviser pour régner”). cf. classes RecursiveAction, RecursiveTask (compute / fork). Attention les tâches parallélisées ne doivent pas faire d’opérations I/O, ni de tâches synchronisées, c’est le meilleur moyen pour provoquer des blocages (et notamment bloquer le Scheduler).Cette notion de parallélisation est très utilisée dans les traitements batch, etc. Pour en savoir plus sur le fork/join : http://goo.gl/tostz ou encore http://goo.gl/7ybgr pour la gestion des ressources.
• Dans un second temps, Julien nous a parlé du projet Coin, qui regroupe un ensemble de développeurs de la JVM avec une communauté qui discute de la pertinence et de la nécessité de faire évoluer telle ou telle partie du langage.
• Une nouveauté parue dans Java 7 est par exemple le try-with-ressources : cela permet de gérer les ressources (flux, sockets) utilisées dans le bloc et de s’assurer de les fermer correctement quel que soit le résultat de l’opération (exception ou déroulement correct). Cela évite d’écrire de nombreux bloc try/catch imbriqués pour fermer proprement les ressources. Voir AutoCloseable. Egalement la gestion du multi-catch, qui permet dans un catch d’intercepter plusieurs types d’erreurs. Cela permet d’éviter que les développeurs ne tombent dans la facilité d’utiliser un catch (Throwable) ou même un catch(Exception) qui récupère les SecurityException, qui sont des exceptions bien particulières.
• Enfin concernant la gestion des génériques, l’opérateur diamond (<>) fait son arrivée. Il n’est ainsi plus nécessaire de déclarer deux fois le contenu de ses listes et autres objets génériques. A voir également : @SafeVarargs, …

En décembre 2011, la session était dédiée au framework Play. Je ne suis pas très adepte ni utilisateur de ces techniques, je ne vais donc pas détailler plus que cela, même si c’était très intéressant de voir une vraie démo assez impressionnante de ce que peut faire cet outil.

Pour en revenir à cette session de février 2012, qui est un peu plus récente, puisqu’au moment ou j’écris cet article, elle date de lundi dernier, nous avons eu l’honneur d’accueillir à Clermont-Ferrand, des employés de l’entreprise poitevine SERLI. Cette entreprise s’est particulièrement fait un nom le jour ou elle à proposé à la communauté Glassfish un module permettant de gérer plusieurs versions d’une même application sur le serveur. La société SERLI existe cependant depuis les touts débuts de l’informatique “grand-public” puisqu’elle date du début des années 1980. Cette société s’oriente de plus en plus vers les développements open-source, et travaille notamment sur des projets tels que Sonar / JoNAS / et bien sûr Glassfish, mais bien d’autres, comme le projet Jaspic qui concerne la sécurité sous JEE, projet intégré dans la version 4 de Glassfish en cours de finalisation.

• Nous avons donc eu dans un premier temps la présentation de Jérôme Petit qui nous a présenté l’activité de SERLI dans le monde open source, ainsi que la possibilité de travailler dans un monde ouvert tout en ayant un modèle économique viable et stable.
• Dans une deuxième temps, Marian Muller, un ingénieur de SERLI toujours, a présenté ses travaux concernant le processus de mise à jour automatique des applications sous GlassFish, notamment par le processus de rolling-upgrade. Le clustering, introduit dans la version 3.1 de Glassfish, permet d’aider au déploiement de nouvelles versions. Au début, Glassfish ne permettant pas de conserver un historique des versions installées sur son serveur. En cas d’erreur sur une nouvelle version, il fallait donc avoir quelque part l’ancienne version et la réinstaller. Dorénavant avec la solution de gestion des versions que propose SERLI, les anciennes versions peuvent être conservées sur le serveur (désactivées) et restaurées en cas d’urgence. La nouvelle version devient alors désactivée et l’ancienne prend la relève. Lors de la phase de mise à jours, de façon standard, les utilisateurs qui sont en train d’utiliser l’application perdent leur session quoi qu’il en soit, et l’application est même indisponible pendant qu’elle est installée sur le serveur. Maintenant, on peut installer une nouvelle version, désactivée et garder l’ancienne activée. Cela permet de ne pas couper le lien avec l’application pendant la phase d’installation (asadmin, commande deploy avec option —enabled=false et un nom d’application + un nom de version, comme par exemple MyApp:versionAlpha) (asadmin une commande sympa à connaître également : asadmin —list-applications —long qui permet d’avoir un rapport détaillé sur chaque version de l’application).
• La notion de rolling-upgrade est la possibilité de mettre à jour l’application progressivement de telle sorte que les clients ne soient pas déconnectés de leur session actuelle. Il existe pour cela plusieurs possibilités. Via l’utilisation de clusters, il faut plusieurs machines. Les clients utilisant l’ancienne version sont petit à petit redirigés vers une certaine machine pendant que les nouveaux clients utilisent les autres machines. Au fur et à mesure que les sessions se libèrent, les machines se mettent à jour avec la nouvelle version. Cette possibilité nécessite un parc conséquent de machines et une architecture réseau assez avancée. Une autre possibilité est le stand-alone rolling upgrade. Encore en phase de validation, cette possibilité permet, pour un serveur de configurer le rolling-upgrade de façon logicielle. Les anciennes sessions sont conservées et pointent vers l’ancienne version du logiciel ; les nouvelles sessions créées pointent vers la nouvelle version du logiciel. A l’aide d’un jeu d’options assez évolué, il est possible de configurer le rolling-upgrade un peu comme on le souhaite (asadmin —deploy, cf. —rolling-upgrade, —keepstate, etc. cf. http://goo.gl/IUc3m pour la documentation complète). Attention, à noter cependant que ces développements s’appliquent surtout pour les applications “web”. Les objets EJB ne sont pas conservés lors d’un rolling-upgrade. Voir alors avec un reverse-proxy la possibilité de gérer ses versions d’une façon plus globale. Un reverse proxy peut diriger vers telle ou telle application (il suffit de les appeler différemment) qui correspondent à des versions spécifiques d’une application générale, en fonction du client d’origine…

Etant conscient que mes résumés ne sont pas forcément très clairs, je vous invite à consulter les slides des diverses présentations sur le site de LavaJUG : http://www.lavajug.org

Et surtout… Longue vie au LavaJUG !