"Et ça continue, encore et encore....". ne me demandez pas pourquoi j'ai cet air dans la tête. ce n'est franchement pas mon style de musique...
Du code, du code, du code...malgré des neurones pas encore complètement "up". Une session au format Tips & Tricks sur certains aspects de la version 5 langage Java. Des subtilités autour des enum ("do not use ordinal()"), des mécanismes de lazy initialization, des generics.
On peut s'étonner du fait qu'on ne parle que de Java5 mais force est de constater qu'encore peu de personnes ont définitivement quitté la version antérieure de Java et que cela reste la version amenant le plus de modification du langage depuis un bout de temps.
...mais ce matin, la keynote s'est concentrée sur la modularité du JDK, la compatibilité et les nouveautés de Java7. Le JDK se doit d'être modulaire pour faciliter les downloads, les temps de démarrage etc....une mouvance que l'on a déjà constaté au niveau des serveurs d'applications (par exemple Glassfish).
"La compatibilité ne sera pas forcément assurée tout le temps" est une synthèse du message de Mark Reinhold sur le sujet de la compatibilité ascendante entre versions du JSE. C'est surprenant, effrayant et en même temps, cela garanti ou facilite la survie du langage Java : certaines fonctionnalités, évolutions du langage se doivent d'être intégrées et la compatibilité est un frein à une réelle intégration...Affaire à suivre.
Les nouveautés du Java 7. On note un mouvement de fond de Sun qui est l'ouverture sur la communauté utilisateur comme si Sun avait compris qu'il était important de faire évoluer le langage pour répondre aux demandes du terrain et donc aux communautés de développeurs. J'aime cette idée. Java 7 intègre donc des évolutions souhaitées par Sun et des évolutions souhaitées par d'autres acteurs:
void doIt() throws X1, X2{
try{}
catch(Throwable e){throw e}
try{...}
catch(X1, X2){
Les architectures orientées évènements fonctionnent sur la base d'évènements échangés entre un "publisher" et un "subscriber". L'utilisateur a alors la responsabilité de s'abonner aux évènements qui l'intéressent; le système s'auto organise (enfin...).
Le Complex Event Processing est une évolution des architectures orientées évènements ou Event Driven Architecture qui vise à agréger beaucoup plus finement qu'un simple Publish/Subscribe des informations, des évènements provenant de différentes sources. Il est possible de requêter le contenu des messages; par exemple, les ordres d'achat qui dépasse tel ou tel montant ou bien les évènements de crédit et débit qui ont en commun un numéro de compte...
Les cas d'utilisation sont autour des systèmes de trading, de détection de fraudes ou bien un système de monitoring de système...
La session est l'occasion de présenter un produit nommé Esper qui implémente et facilite (normalement bien entendu car rappelez vous qu'il s'agit d'une présentation...) le développement de systèmes basées sur cette architecture. Esper propose donc une API permettant de réagir aux évènements, d'en créer de nouveaux, de requêter le contenu des message avec une syntaxe proche de SQL.
Je crois que je n'aurai jamais autant entendu ce terme: modularité. Cette présentation se concentre sur la JSR-294 ou comment gérer la modularité de JDK mais également des applications afin d'améliorer quelques limitations sur l'existant:
Bref, cette JSR veut faire évoluer le langage et la VM pour être plus simple et flexible. Alors voilà dans les grandes lignes ce qui nous attend (au risque de ne pas être exhaustif). En premier lieu, le concept de module. le package est hiérarchique. le module, lui, permettra de regrouper des classes de différents packages dans un composant "logique". Ainsi le code suivant pourra être écrit
module com.octopackage com.octo.core public class DoIt
puis dans une autre classe
module com.octo package com.octo.ext module class DoItDifferently
la classe DoItDifferently utilise le mot-clé module qui lui donne simplement la visibilité - et donc la possibilité d'être utilisée - au sein du module, indépendamment de son package.
Mais le module introduit également la gestion des dépendances. Ainsi il peut référencer d'autres modules qu'ils utilisent et que la JVM aura à charge de récupérer (comment? ca non plus je n'ai pas compris...ben oui désolé.)
module com.octo{ require com.octo.core require ceQueVousVoulez }
Bien entendu, il faut rajouter les notions de versionning; là encore, c'est le développeur qui gère cela.
module com.octo @ 1.2{ require com.octo.core @ 1.2 require ceQueVousVoulez @ 2.2 }
Il reste à voir comment la JVM va gérer ces dépendances de modules. Reste qu'à ce jour, ces évolutions du langage me semblent plutôt destinée aux éditeurs mais cela risque d'impacter nos processus de build car aujourd'hui des outils comme Maven gère pour nous et au build ces histoires de dépendances et de version de binaires. Peut être que la JSR 294 aura le même destin que sa quasi homonyme JSR- 277; Java Module. Peut-être pas.
Là encore, le keyword est "modularité". JEE continu à grossir par rapport à sa version précédente mais introduit la notion de profile. L'idée dérrière les profiles est de regrouper des technologies "cohérentes" entre elles. Le premier de ces profiles est le "Web Profile" ou quelles sont les APIs nécessaires et utiles pour réaliser une application Web complète. Ainsi, le Web Profile va réunir Servlet 3.0, JSP 2.1, JSF 2.0, EJB Lite 3.1, JTA 1.1, JPA 2.0..Un beau programme mais la limite ou la difficulté auquel Sun devra faire face avec les profils, c'est de créer le consensus sur ce quelles APIs seront présentes ou non dans le profile...Au regard des réactions du public, la tâche me parait complexe.
"Faute avouée est à moitié pardonnée" disait ma mère (et en fait j'imagine toutes les mères...). Sun appelle le "pruning" ou comment déprécier des pans complet de JEE; les éditeurs auront le choix d'implémenter ou non ces parties. On y trouve des APIs comme JAX-RPC...
JEE 6 s'ouvrira également sur la communauté au proposant les "Extensibility"; un mécanisme permettant à des solutions open source, des framework comme Spring, de bundler leur configuration (typiquement les servlet-filter...) pour que cette dernière soit simplement et de façon transparente, pour le développeur, prise en compte par le container.
Pour aller un peu plus dans le détail. Servlet 3.0 propose :
Concernant EJB 3.1, on note:
Commencons par le but du produit : supprimer le turnover; ie le temps entre une modification du code et la visualisation du changement dans une application déployée sur un serveur.
La présentation commence par poser le problème : en tant que développeurs Java d'application web, on passe 10% du temps à attendre que notre application se redéploie et a peu pès autant à retrouver ce qu'on était en train de faire vu que pendant notre temps d'attente, notre cerveau à perdu le fil. Bref, chaque seconde compte.
Des solutions plus ou moins bonnes existent déjà.
Javarebel est assez similaire a hotswap : il change directement le code des objets (donc pas de rechargement de contexte), mais il supporte lui plus de fonctionnalités comme l'ajout de méthodes, de variables d'instances, de classes etc... Les limitations sont repoussées aux changement d'héritage (l'objet n'étant plus X mais Y par exemple).
Une partie de certains frameworks comme Spring ou Struts sont aussi gérés (tant que la configuration est gérée par annotation dans la classe) : par exemple, on peut rajouter à chaud une méthode d'un controlleur spring avec l'annotation qui va bien pour qu'elle soit bindé sur l'URL correspondante, ou encore on peut rajouter un bean "autowired", le bean sera mis à jour automatiquement.
Des plugins sont prévus pour intégrer ce produit aux outils comme Maven ou Eclipse.
Conclusion du speaker : "chaque secondes comptent. Il y a plein de solutions efficaces, gratuites et qu'il faut utiliser, si vous voulez aller encore plus loin, il y a une solution payante (mais pas chere)" . A noter, que vous pouvez payer en bières si vous voulez (4 pour la version individuelle et une dizaine pour la version entreprise)
La société développe aussi un serveur d'application basé sur la même technologie qui vous permet de réaliser une montée de version de votre application avec zéro interruption de service.
Session très intéressante qui énumère toutes les optimisations possibles et leur contexte d'application. Toute la chaîne participant à la persistance est passée en revue, on commence par parler des paramétrages au niveau de l'OS (et oui, à la fin nos données son bien sauvegardées sur de vulgaires fichiers ;-), les accès disques (compression, cryptage, fragmentation), communication réseau, etc... Puis on remonte d'un niveau pour aborder la base de données et les configurations permettant là encore de gagner en performance: la taille du cache (the bigger, the better ;-), les indexs, la taille des buffers, les table space... là on se dit, tiens je vais aller payer un café à mon DBA préféré ;-) Puis on remonte doucement vers Hibernate (en abordant le choix judicieux du driver JDBC); petite piqure de rappel sur les différents caches Hibernate (1er et 2ème niveaux). On entre ans le vif du sujet avec les optimisations au niveau code et design d'implémentation: on prendra bien soin de ne pas avoir une hiérarchie d'héritage trop importante, de bien choisir le type de la colonne discriminante (on préférera utiliser un char(1), certes moins explicite mais bien plus performant.
Idée reçu: le DDL automatiquement généré par hibernate n'est pas optimisé pour la production ! Volker insiste bien sur le fait de se rapprocher le plus possible du DBA pour qu'il puisse "tuner" les scripts de génération et poser correctement les bons indexs (sans doute l'optimisation qui fournit le meilleur retour sur investissement). La session se termine par l'optimisation des requêtes HQL: toujours utiliser les "parametrized queries", maximiser les bulks/batch invocation pour optimiser les allers-retours vers la base de données, préférer le eager-loading pour les cas d'utilisation de navigation dans les grappes d'objet...
L'optimisation des performances s'effectue à de très nombreux niveaux depuis les fichiers jusque dans le code de l'application. Pour que ce chantier soit utile et concluant, Il ne faut jamais oublier de se fixer un objectif... et là, le test de monté en charge nous aidera pour fixer cet objectif à atteindre grâce aux métriques que nous pourront alors suivre.
Les nouveautés de Maven 3 :
L'équipe travaille avec Hudson pour offrir une meilleure intégration de Maven, notamment grâce à l'embedder. Une intégration de workflow (via drools) permettra de définir un workflow pour une release par exemple : "build - envoi de mails - vote des intéressés - release".
Au final, un gros accent sur la modularité et l'intégration aux outils du développeur, Jason van Zyl nous à fait une bonne démo de m2eclipse et l'objectif est clairement que le développeur reste dans son IDE et que celui-ci lui apporte tout ce qu'il a besoin : documentation pour construire son projet, autocomplétion, vue sur les repositories centraux, etc...
By Benoit Lafontaine, Fabrice Robini, Olivier Mallassi