Là où certains scandent le mot fraternité, d'autres plus proche du monde IT semblent adopter le mot modularité. Quand je pense que sur les bancs de l'école on nous disait alors que l'approche objet permettait la réutilisabilité, qu'on allait pouvoir travailler indépendamment sur des couches (modules) distinctes et réutilisables... En fait en prenant un peu de recule, en phase de développement effectivement nos packages nous permettent de correctement distinguer les couches d'accès au données, présentation, etc. En plus si on utilise des frameworks comme maven, la structure de notre projet fera clairement apparaître nos différents artefacts en vue du build. Mais force est de constater qu'une fois le build effectué, l'archive à déployer fera moins apparaître cette modularité. Prenons un EAR, certes il sera par exemple composé d'un war et d'un ou plusieurs JAR pour les couches de services et d'accès aux données, mais dans un tel découpage on retrouvera les classes métiers, les interfaces des façades, et toutes les classes communes aux différentes archives.
Java 7.0 et la modularité
Comme le fait remarquer Alex Moussine Pouchkine (Architecte Java chez Sun) : "le système de package de Java est obsolète et pose les mêmes problème que les DLL de Microsoft". La JSR 277 a donc vu le jour chez SUN pour remplacer le système d'archive actuel (jar, war et ear) et la première implémentation de cette JSR devrait voir le jour dans la prochaine version du JDK, soit Java 7.0. Issues de la spec, voici les réponses que devra apporter cette JSR 277 également appelée Java Module System (JMS rien à voir avec Java Messaging System) :
- Un nouveau format de distribution des classes java et ressources associées, ainsi qu'un nouveau format pour les métadonnées associées au module.
- Une spécification pour réaliser un référentiel de modules (exit les référentiels Maven ??)
- Les métadonnées indiqueront :
- une description du contenu du module
- les dépendances vis à vis d'autres modules en précisant les versions de ces derniers
- l'ensemble des ressources (Java et autres) accessibles depuis d'autres modules
Je ne sais pas ce que vous en pensez, mais ça me rappelle étrangement la notion de bundle OSGi, comme les plugins Eclipse, dans lesquels on trouve exactement les mêmes notions. J'avoue partager le constat sur les limitations des archives d'un point de vue modularité, mais de là à définir un nouveau standard... serait-ce un choix politique plutôt que technique ? Pour aller plus loin, je vous conseille ce billet provenant de l'OSGi Alliance.
GlassFish et la modularité
Au delà de la prochaine version de Java, on parle également de la sortie prochaine de Java EE 6 et surtout du premier serveur d'application qui implémentera cette nouvelle mouture : GlassFish V3. Les atouts mis par Sun pour la nouvelle version de GlassFish sont : la modularité, l'extensibilité, la possibilité de déployer ou supprimer de nouveaux services "à chaud". Cette approche permettra de définir des profils d'utilisation de GlassFish et donc de supprimer certains services couteux (RMI, JMS, JNDI, EJB, WS, etc.), mais Sun nous indique qu'il sera possible de réinstaller ces services à tout moment et sans redémarrer le serveur d'application. Pour parvenir à ce résultat la plate-forme de GlassFish reposera sur... OSGi (?)