je suis en train de travailler sur la « bundlisation » de JTheque Core. Comme le core proposait un certain nombre de services, j’ai commencé par découper le gros jar qu’était le core en une série de bundles offrant tous un service bien précis.

Je me suis vite rendu compte que le découplage de mes différents services était à peu près nul. J’avais un nombre énorme de dépendances pour chaque bundle et pire encore, j’avais un grand nombre de dépendances cycliques, soit directs soit indirects.

Pour information, une dépendance cyclique directe est une situation dans laquelle un bundle X dépend d’un bundle Y qui dépend lui-même de X. Une dépendance cycle indirecte est la situation dans laquelle X dépend Y, Y dépend de Z et Z dépend de X. Je parle ici de bundles, mais cela peut concerner des projets, des classes ou des packages.

A noter que les différentes techniques que je vais présenter s’appliquent également pour des dépendances entre composants non-OSGi, les principes sont tout à fait les mêmes.

Dans le cas de packages à l’intérieur d’une même application, même s’il faut éviter cela, il est possible de vivre. Néanmoins, dans le cas de bundle ou de projets, il n’est en général même pas possible de builder l’application. Dans mon cas, les bundles sont des modules Maven. Il est donc impossible de lancer le build d’un bundle dans un cycle puisqu’il faut builder le premier bundle avant le second et le second avant le premier, ce qui n’est pas évidemment pas possible.

En plus d’être très mauvais dans un système de build, les dépendances cycliques entre componsants sont aussi un énorme problème de conception. En effet, on ne peut plus travailler sur le bundle A sans travailler sur le bundle B et vice-versa. En plus de cela, les deux composants sont très difficiles à faire évoluer de manière saine.

Les dépendances cycliques au niveau des classes à l’intérieur d’un composant ne posent pas vraiment de problèmes. On est toujours dans le même composant, les classes peuvent dont être liées de manière cyclique, même s’il faudrait tout de même éviter cela dès que c’est possible (ça ne l’est pas toujours).

Pour en revenir à JTheque, j’ai donc du résoudre ce problème de dépendances cycliques avant de pouvoir avancer plus loin. Il existe beaucoup de techniques permettant de faire cela. Voici les différentes pistes que j’ai explorées pour résoudre ces dépendances. A noter que ces techiques ne permettent pas seulement de règler le problème des dépendances cycliques mais permet aussi d’améliorer l’architecture de son application.

1. Déplacer les classes au bon endroit : Dans certains cas, j’avais des classes dans un bundle alors qu’elles n’avait rien à y faire. Dans ce cas-là, il peut suffir de les dépacer dans un autre bundle. A noter que ce cas est le plus simple à résoudre et que ce n’est malheureusement pas le plsu courant. En plus de cela, dans le cas ou la/les classes à déplacer sont dépendantes d’autres bundles, il est possible que cela crée de nouvelles dépendances cycliques. Un exemple est une classe de gestion de modules qui était contenues dans le bundle d’interfaces graphiques.

2. Déplacer les fonctionnalités : J’ai également trouvé beaucoup de fonctionnalités, typiquement des fonctions, à l’intérieur d’un bundle qui n’étaient pas au bon endroit. Par exemple le bundle « modules » permettait de faire des mises à jour alors qu’un bundle « update » existait. Il m’a suffi de déplacer cette fonctionnalité de mise à jour vers le bundle update pour résoudre ma dépendance.

3. Fonctionnalités mal découpées : Il arrive souvent qu’une fonctionnalité, généralement une méthode ou une classe, fasse trop de choses et entraîne des dépendances qui ne sont pas bienvenues ici. Souvent bien redécouper les fonctionnalités et donc le rôle de chaque classe/méthode peut suffir à régler le problème. A noter que ceci ne concerne pas uniquement les concepts de dépendances, mais est un principe de base de la conception orientée objet. Dans le cas de JTheque, j’avais pas par exemple, une permettant permettant de choisir une collection qui retournait true si on pouvait ouvrir la collection avec le couple login/password entré sinon false. Mais en plus de cela, elle affichait une erreur dans la vue de choix de collection s’il y avait un problème alors que ce n’était pas du son rôle. J’ai mis à jour cette méthode pour qu’elle ne fasse que tester si on pouvait ouvrir la collection ou non et j’ai implémenté l’affichage de l’erreur au niveau de l’action Swing.

4. Découper les fonctionnalités du bundle : Il peut arriver que le bundle fasse trop de choses ou ait plusieurs aspects bien distincts. Dans ce cas, il faut tout de suite séparer le bundle en plusieurs autres pour que chacun ait une responsabilité claire. Souvent cela va aider à résoudre une dépendance cyclique, comme moins de bundles auront des dépendances vers chacun des nouveaux bundles et que chacun des nouveaux bundles devrait avoir moins de dépendances vers d’autres bundles. Mais cela peut également introduire de nouveaux cycles car on peut mal séparer les composants et se retrouver avec 2 composants cycliquement dépendant, on n’aura alors fait que déplacer le problème. Dans JTheque, j’ai découpé le modules vues en 2 deux bundles : vues et ui. Le module vues contient l’implémentation des vues de JTheque alors que le module ui contient des classes utilitaires pour la création de vues ainsi que des composants Swing génériques qui peuvent être utilisés ailleurs.

5. Introduire un système de CallBack : Un système de CallBack est un simple système de listeners qui peut permettre de résoudre des dépendances. Au lieu qu’un bundle avertisse directement un autre bundle, il suffit que le second s’enregistre sur le premier comme listener. Ainsi le premier n’a plus besoin de connaître le second. On voit tout de suite que les listeners sont donc plus puissants qu’on ne pourrait le croire au premier abord. Dans le cas de JTheque, j’ai implémenté cela pour le choix des collections. En effet, de base, le gestionnaire de collections appelait directement la vue pour dire que la collection avait été choisie. En passant à un listener, cela est beaucoup plus souple et le gestionnaire de collections avertit automatiquement tous les écouteurs. En plus de cela, si j’ai besoin plus tard d’ajouter un second écouteur, je n’ai rien à changer du côté du bundle collections.

6. Séparer la spécification de l’implémentation : Comme il n’est pas toujours possible de supprimer les dépendances cycliques directement, on peut donc les contourner en séparant la partie de spécification de la partie d’implémentation. Cette technique n’est clairement pas la meilleur mais peut parfois être utile quand il est vraiment difficile de résoudre le cycle. On sépare donc dans un bundle toute la partie spécification qui est appelée de l’extérieur et la partie d’implémentation qui peut alors avoir des dépendances avec l’extérieur. A noter que ce n’est clairement pas souvent faisable en l’état car il n’est pas toujours possible de complètement séparer l’implémentation de la spécification sans cycles. Je n’ai pas utilisé cette technique dans JTheque, mais j’y ai pensé.

7. Regrouper 2 bundles en un seul : Dans certains cas, on se rend compte que deux modules sont si intrinsèquement liés qu’ils ne forment en fait qu’un seul modules. Dans ce cas, la meilleure solution est de les regrouper en un seul bundle.

Voilà, j’ai maintenant passé en revue les différentes techniques que j’ai utilisées pour résoudre les dépendances cycliques dans les bundles de JTheque Core. Il en existe très certainement de nombreuses autres, mais personnellement, elles m’ont suffit.

J’espère que cela pourra être utile aux personnes cherchant à résoudre des problèmes de dépendances cycliques.

Je suis actuellement en train de développer une application modulaire. Au vu des problèmes que j’ai rencontré pour développer la partie modules et le peu d’informations que j’ai pu trouver sur le net, j’ai pensé que faire une série de billets sur le sujet ne pourrait qu’être profitable à tout le monde.

Dans ce billet, je vais commencer par parler des bases de la conception d’une application modulaire, c’est-à-dire pour commencer, ce qu’est une application modulaire, ce qu’est un module et bien entendu ce que ça apporte. Dans les prochains billets, je vais essayer de décrire les différentes problématiques inhérentes au sujet et leurs résolutions. Si ces billets nécessitent du code, ces exemples de code seront en Java, car c’est le langage que j’ai choisi pour développer mon application, mais les concepts peuvent s’appliquer à tous les langages.

Bien entendu, je ne me considère pas comme un pro dans les applications modulaires et les différentes informations que je vais donner au fil des billets n’est que ma façon de voir, il y en a certainement d’autres et des meilleures, donc si vous n’êtes pas d’accord avec moi ou si vous pensez qu’on peut faire mieux, n’hésitez pas à réagir en commentant ces billets

Pour commencer, qu’est-ce qu’une application modulaire ? Une application modulaire est constituée de 2 parties bien distinctes :

• Le coeur : Comme son nom l’indique, il s’agit de la partie centrale de l’application. Cette partie doit être complètement indépendante des modules.
• Les modules : Il s’agit cette fois des parties qu’on va ajouter dynamiquement à l’application pour lui rajouter des fonctionnalités. On leur donne d’autres noms : briques, plugins, addons, …, mais le concept est toujours le même.

Il y a à mon avis 2 sortes d’applications modulaires. Le premier type est une application somme toute normale qui propose une série de fonctionnalités et qui propose en plus de rajouter des fonctionnalités par le biais de modules. Le second type est une application qui propose un coeur complètement dénué de fonctionnalités. Toutes les fonctionnalités sont proposées par les modules, c’est donc une application dans laquelle « tout est module ».

La différence principale est que la première peut être utilisée tout à fait normalement sans aucun module, alors que la deuxième ne propose pas (ou presque pas) de fonctionnalités sans module.

Au contraire d’une application normale, il faut donc prévoir des points d’extensions que les modules pourront utiliser pour ajouter des fonctionnalités à l’application ou pour modifier l’existant.

C’est sur ce deuxième type d’application modulaire que je suis parti pour réaliser mon logiciel. Cela permet d’avoir un socle solide qu’on peut éventuellement réutiliser pour d’autres applications sous réserve de quelques modifications.

Comme application modulaire connue, on peut citer Eclipse qui est entièrement modulaire et qui est du deuxième type.

Maintenant, la grande question est : C’est bien beau tout ça, mais ça sert à quoi ? Tout d’abord, du point de vue du développeur, cela permet de séparer clairement les différentes parties de l’application. On a donc des modules distincts plus faciles à maintenir qu’une grosse application. Cela permet également d’être très souple pour rajouter des fonctionnalités à l’application, en effet, pour cela, il suffit de créer un nouveau module, d’y coder la fonctionnalité et de rajouter ce module dans l’application. Du point de vue de l’utilisateur, cela ajoute de la souplesse au programme. En effet, l’utilisateur va pouvoir choisir quels modules il veut lancer, rajouter de nouveaux modules, voire même en créer s’il en est capable. Il pourra donc personnaliser son application.

Bien entendu, cela ne se fait pas tout seul et ce n’est pas des plus simples à concevoir et à implémenter. En effet, cela pose beaucoup de problématiques qu’il faut régler et cela implique beaucoup de questions qu’il faut se poser.

C’est ce que nous verrons dans les prochains articles.

Nous avons dit qu’un module permettait de rajouter des fonctionnalités à l’application principale. Mais avant de se lancer dans le moindre code, il va falloir définir exactement ce que seront nos modules, ce qu’ils pourront faire, s’il y aura plusieurs types de modules, …

C’est ce que nous allons voir dans ce billet.

La première question à se poser est : « Que vont pouvoir faire mes modules ? ». C’est-à-dire, qu’est-ce qu’un module pourra ajouter à l’application principale.

Nous avons dit qu’un module rajoutait des fonctionnalités à l’application principale, mais il faut maintenant spécifier ce que les modules pourront ajouter et la manière dont ils vont pouvoir les ajouter. En plus d’ajouter, un module pourra éventuellement modifier l’application principale.

Ce que les modules pourront faire va dépendre également du type d’application modulaire :

• Dans le cas du premier type (application normale avec possibilité d’extension par module), le module va rajouter des fonctionnalités de types spécifiques, c’est-à-dire en accord avec l’application. Prenons le cas d’une application qui permet de regarder la télévision via internet. Dans ce cas-là, les modules pourront par exemple rajouter une chaîne à l’application ou rajouter un format de conversion vidéo pour l’enregistrement. Il peut aussi rajouter une fonctionnalité complète comme des statistiques qui indiqueraient le nombre d’heures pendant lesquelles on a regardé la télé sur ce programme et la chaîne la plus regardée.
• Dans le cas du second type (application vide de base et modules qui rendent l’application utilisable), les modules ne vont pas rajouter des fonctionnalités à l’application principale étant donné qu’elle ne permet rien, mais vont définir ce que va faire l’application. Cette fois, les modules, c’est l’application. Prenons mon application (JTheque) qui est destiné à gérer des collections diverses. J’ai pour le moment un module Films et un module Livres. J’ai ensuite des plus petits modules comme le modules Stats ou un module qui permet de gérer une liste de films à acheter. On voit qu’on a déja des modules beaucoup plus large. En plus, avec quelque chose de ce type, on pourrait imaginer une module qui ferait quelque chose de complètement différent de l’application de base, comme un module Calculette qui ajouterait une calculatrice à l’application, ce qui n’est pas du tout le but de l’application de base mais qui est rendue possible par les possibilités d’extension du coeur de l’application.

Dans ces deux cas, il faut donc définir certains points d’extension. Dans le cas de JTheque, voici les points d’extension que j’ai créé pour mes modules :

• Rajouter des onglets dans la vue principale
• Rajouter des composants dans la barre d’état
• Rajouter des éléments dans le menu de la vue principale
• Rajouter des onglets dans la vue de configuration

A partir de ces points d’extension, les modules peuvent faire beaucoup de choses. Par exemple, si on veut faire une calculette, on peut imaginer rajouter un onglet principal avec une calculette, ou alors faire une fenêtre dediée et rajouter un élément dans le menu qui ouvrirait cette fenêtre.

Ceci est donc laissé au libre choix du développeur, mais il faut y penser avant et bien réfléchir à ce que ça implique.

En plus de points d’extension, le coeur de l’application fournit aussi une série de services aux modules. Ces services peuvent être de simples classes utilitaires ou alors un gestionnaire de persistence d’entités, un gestionnaire de log ou encore un gestionnaire permettant aux modules d’enregistrer des informations pour les retrouver après l’arrêt de l’application.

Là encore ces points sont laissés à la discrétion du développeur. Ces services ne sont pas obligatoires, mais cela permet d’éviter que chaque module doivent tout refaire. En plus, cela permet également une standardisation. En effet, les modules vont (normalement) utiliser le même type de persistence, le même type de log, … Ce qui est plus facile à gérer ensuite. Bien entendu, rien n’empêche un module d’utiliser son propre système de log si celui du coeur ne lui convient pas.

Pour la petite histoire, voilà les services que j’offre à mes modules :

• Gestionnaire de logs : Permet aux modules d’obtenir des loggers (Log4J) pour logger différentes actions.
• Gestionnaire d’erreurs : Permet aux modules d’afficher des erreurs facilement
• Gestionnaire de vue : Permet aux modules d’afficher des messages, de demander quelque chose à l’utilisateur, …
• Gestionnaire de beans : Permet aux modules d’utiliser de l’IOC (Spring).
• Gestionnaire de ressources : Permet aux modules de bénéficier de l’internationalisation (Spring) ainsi que d’un cache d’image
• Gestionnaire de persistence : Permet aux modules de gérer des entités persistentes (JPA/Hibernate).
• Gestionnaire d’états : Permet aux modules de stocker des états.

On peut aussi réfléchir si on veut un seul type de module ou s’il y en aura plusieurs. Dans mon cas, j’ai fait une petite distinction entre des modules dits principaux et des modules dits secondaires. Les fonctionnalités sont exactement les mêmes sauf qu’un seul module principal peut être lancé en même temps. Par exemple, le module films est un module principal et le module ajoutant une liste de films à acheter est un module secondaire.

Le dernier point que je vois à traiter au niveau des modules est la dépendance entre modules. On peut permettre ou non qu’un module dépende d’un autre module. Cela ajoute un niveau de difficulté supplémentaire au niveau de l’implémentation étant donné qu’il faudra vérifier que la dépendance est remplie avant de pouvoir lancer le module. Cela implique également que le module principal doit être lancé avant le module qui en dépent. Et que faire des dépendances circulaires ? Bref, cela est également laissé au choix du développeur qui peut permettre les dépendances intra-modules ou non. Dans mon cas, je l’ai permis, j’ai par exemple, le module Stats qui dépend du module Films étant donné qu’il a besoin des informations sur les films, acteurs et réalisateurs pour générer ses statistiques.

Voilà, j’en ai fini (enfin, me direz-vous ^^) avec les caractéristiques des modules. Comme pour le premier article, n’hésitez surtout pas à vous manifester si vous avez des questions ou si vous n’êtes pas d’accord avec quelque chose que j’ai dit ou si vous aimeriez plus d’informations sur un point spécifique

Il nous faut donc un conteneur pour notre module qu’on puisse ensuite charger depuis notre application principale.

Nous allons maintenant voir ce que sera un module au niveau Java.

Comme un module est complètement indépendant de l’application principale, on ne peut inclure directement le module dans l’application principale, il faut distinguer le fichier du module de celui de l’application principale.

Il faut maintenant définir ce que vont être ces fichiers. Comme est au niveau Java, on peut s’imaginer les modules comme des extensions de l’application principale. Or pour étendre une application Java, on utilise des fichiers Jars.

Nos modules seront donc contenus dans des fichiers Jars.

Voici pour ce qui est de la manière de représenter physiquement un module, nous allons voir comment le représenter pour qu’il soit utilisable au niveau Java.

Nous allons donc créer une interface permet de décrire les caractèristiques principales d’un module. Nous allons rester simple pour le moment. Un module doit tout d’abord être rattachable et ensuite détachable. C’est-à-dire le moment ou il va se rattacher à l’application, c’est-à-dire l’étendre et le moment où il va se détacher de l’application. En plus de cela, un module a aussi un nom. Pour le moment, ce sera tout ce dont on a besoin.

On va donc avoir une interface tout simple décrivant notre module :

On pourrait donc créer un module très simple affichant quelque chose sur la console :

Nous allons donc créer un fichier Jar contenant notre classe.

Il faut maintenant une solution pour que l’application principale connaisse cette classe pour la lancer. Il faut donc un moyen pour qu’elle trouve cette classe.

On pourrait imaginer parcourir le fichier jar et tester pour chacun des classes si c’est un module ou non. Cette méthode bien que fonctionnelle n’est pas du tout optimale car elle implique de parcourir toute l’archive ce qui risque de prendre du temps dans le cas de gros module. Alors, on va utiliser les outils que nous offre Java et ajouter une mention dans le manifest du jar pour indiquer à l’application principale quelle est la classe du module à charger.

Voilà à quoi ressemblerait notre Manifest pour notre petit module :

Cela permettra à l’application principale de savoir quelle classe charger.

Je montrerai dans mon prochain billet une manière de charger ces modules. Car il ne suffit pas de mettre ces fichiers jars dans le classpath pour les charger étant donné que l’application principale ne doit pas connaître les modules.

Au niveau de Java, les classes sont chargées depuis des ClassLoader qui comme son nom l’indique est un chargeur de classes.

De base, Java utilise le ClassLoader système pour charger les classes dont notre application a besoin et ce ClassLoader contient les classes de notre application et toutes les classe qu’il a pu découvrir dans le classpath qu’on lui a fourni.

Le problème est que dans notre cas, on ne peut pas vraiment ajouter les fichiers Jar des modules au classpath étant donné que l’application ne connait pas les modules.

De plus, on ne peut théoriquement pas modifier le ClassLoader système. Je dis théoriquement, parce qu’il est possible de rajouter des fichiers ou des ressources à un ClassLoader en utilisant la réfléction et en appelant une méthode non publiques, mais je ne trouve que cette méthode soit très propre.

Nous allons donc devoir créer un nouveau ClassLoader avec lequel nous allons charger les classe de nos modules.

Il nous faudra donc procéder en deux phases :

• La première servira à explorer les fichiers des modules, à en sortir la classe du module et à récolter les URLs des fichiers Jar
• La seconde va charger les différents modules en se servant d’un ClassLoader créé avec les URLs collectées durant la première phase.

On va donc créer une classe ModuleLoader qui va nous permettre d’effectuer ces phases.

Prenons maintenant la première phase et créons une méthode qui retourne la liste des classes à charger.

Comme vous le voyez, ce n’est pas très compliqué, on parcours les fichiers Jar existant dans le dossier des modules, on ouvre le fichier Jar, on récupère le manifest et on récupère la classe du module. Ensuite de quoi, on ajoute encore l’URL du fichier Jar à la liste des URLs.

Bien entendu ce code est perfectible, il faudrait traiter le cas ou le fichier JAR n’a pas de manifest ou alors le cas ou le manifest n’a pas de classe de module et il faudrait traiter les erreurs correctement, mais ce n’est pas le but de ce billet.

On peut maintenant passer à la deuxième méthode qui va créer le ClassLoader et instancier les modules puis les retourner :

On commence donc créer un nouveau ClassLoader à partir des URLs qu’on a récupéré avec les fichiers JARs. On va utiliser un URLClassLoader qui permet de charger des classes depuis des emplacements définis par des URLs. On va lui donner comme parent le ClassLoader de la classe. Comme cela les modules qui utiliseront ce classloader pourront également utiliser les classes de l’application, ce qui est le but d’une application modulaire. Une fois qu’on a créé notre ClassLoader, on va parcourir toutes nos classes et les instancier si elles implémentent bien la bonne interface. Ensuite, on va pouvoir les ajouter à la liste et les retourner.

Encore une fois, ce code est perfectible, il faudrait traiter les erreurs et réagir aux différents cas possibles, mais j’ai essayé de faire au plus court.

Notre chargeur de modules est donc terminé.

Nous pouvons tester notre application en créant un Jar pour le module que nous avons défini dans le billet précédent et en créant un code tout simple pour les charger :

Voici ce que rendrait l’éxécution :

Plug : Simple module
Hello kernel !
Déroulement de l’application.
Bye kernel !

Comme vous le voyez, nous venons de développer une application modulaire. Bien entendu, il faut ensuite développer tous les services et les points d’extension, mais ces points sont spécifiques à l’application.

La technique présentée dans ce billet pose néanmoins un problème pour ce qui est du déploiement à la volée de module. En effet, si on charge un module après le chargement des premiers modules, on devra recréer un nouveau ClassLoader et on aura donc une partie des modules dans le premier ClassLoader et une partie des modules dans le second ClassLoader. Néanmoins, si les modules n’ont aucune intéraction entre eux, vous pouvez tout à fait envisager cette méthode pour le déploiement à la volée. Si ce n’est pas le cas, vous serez obligé de vous rabattre sur la méthode avec réfléction pour ajouter des modules dans votre ClassLoader. Je présenterai peut-être cette méthode dans un prochain billet.

Le fait d’avoir un deuxième ClassLoader pose également un problème pour les librairies qui chargent des classes à la volée comme par exemple Spring IOC ou Hibernate. Il faut voir au cas par cas pour ces librairies comment on peut leur spécifier d’utiliser notre ClassLoader. Souvent ceci est faisable en spécifiant le contextClassLoader via la méthode Thread.currentThread().setContextClassLoader(ClassLoader cl).