Je poste juste ici pour donner quelques informations sur mon nouveau projet : eddic.

eddic est un compilateur, écrit en C++, permettant de compiler un language que j’ai « imaginé » EDDI. Le compilateur et le langage sont encore vraiment limités. eddic génère de l’assembleur qui est ensuite assemblé avec as et linké avec ld.

Actuellement en version 0.6.0, EDDI supporte :

• 2 types : int et string
• Les expressions mathématiques avec les opérateurs +-*/%
• La concaténation de string
• Les variables, locales et globales
• Les branches conditionelles if, else, else if
• Les expressions booléennes pour les branchements et les boucles
• Les boucles for, foreach, while
• Les tableaux, globaux ou locaux
• L’appel de function, mais pas de valeur de retour

Je suis en train de développer la version 0.6.1 qui va inclure quelques refactorings et le support des retours de functions.

Le code est disponible sur Github : https://github.com/wichtounet/eddic
Pour plus d’informations, vous pouvez aussi lire mes posts à ce sujet : http://www.baptiste-wicht.com/tag/eddi/

N’hésitez pas à me faire part de tous les commentaires et idées que vous pourriez avoir

Mais petit à petit, je me suis rendu compte que Maven 2 était beaucoup plus intéressant que je ne le pensais et offrait des possibilités beaucoup plus élevées qu’Ant.

J’ai donc gentiment intégré petit à petit les possibilités de Maven 2 tout d’abord pour remplacer mes petits scripts Ant, ensuite dans mon système d’intégration continue puis maintenant pour ce qui est de la génération de site et du déploiement automatique d’artifacts.

Et je dois dire que je suis de plus en plus ravi par cet outil super complet. Il me permet de faire des builds beaucoup plus complets qu’Ant, me génère automatiquement des rapports et un site et me permet de déployer le tout directement sur mon serveur FTP sans aucun problème. C’est donc un gain de temps non négligeable. Bref que du bonheur.

Bien qu’il faille un certain temps d’adaptation et d’études pour appréhender correctement l’outil, une fois qu’on en a saisi la philosophie, il est assez facile d’avancer et d’intégrer petit à petit les immenses possibilités de Maven 2. Je suis d’ailleurs encore loin de toutes les connaître et les utiliser.

Néanmoins, il y a quand même quelques petits problèmes que j’ai pu constater. Premièrement, la prise en main n’est pas des plus facile. La philosophie est en effet tout à fait différente de ce que l’on trouve dans les système de build basé sur le script. Ensuite, la documentation n’est pas toujours des plus clairs, surtout en ce qui concerne les projets multi-modules. Et enfin, beaucoup de choses se répètent dans les POM de différents projets, mais pour ce point là, je l’avais déjà avec Ant.

Pour conclure, je dirais que Maven 2 est infiniment plus puissant et agréable à utiliser qu’Ant et bien qu’il faille un certain temps pour le prendre en main, n’est pas des plus difficiles à utiliser.

Je viens de mettre à jour le site de JTheque (http://jtheque.developpez.com) avec les dernières informations sur les modules, les applications, …

En plus de cela, le site est maintenant devenu multilingue (Français – Anglais).

N’hésitez pas à m’indiquer si vous trouvez des bugs sur le site ou si vous voulez donner votre avis sur le site. Vous pouvez réagir directement sur le forum.

J’ai le plaisir de vous annoncer que j’ai développé une nouvelle application basé sur le core JTheque : JTheque Metrics.

Cette application permet de générer des métriques sur le code d’un projet Java.

Pour le moment, les métriques générées ne sont pas très nombreuses :

• Nombre de lignes
• Nombre de lignes de code
• Nombre de lignes de commentaires

Mais cela devrait évoluer

JTheque Metrics gérer les projets multi-modules. C’est-à-dire que vous pouvez enregistrer un nouveau projet et lui spécifier plusieurs sous-projets (des dossiers).

Vous pouvez également enregistrer une configuration de projet pour ne pas avoir à le reconfigurer entièrement plusieurs fois.

Vous pouvez télécharger le programme ici.

Les sources :

• Module principal
• Application

La Javadoc :

• Module principal
• Application

En espérant que ce programme vous soit utile.

N’hésitez pas à me faire part de votre avis, de vos propositions d’amélioration ou des bugs que vous auriez pu constater sur le forum.

J’ai effectué plusieurs modifications au niveau de JTheque.

Tout d’abord, je viens de créer un nouveau module : JTheque Movies Module.

Ce module, encore très basique, permet de gérer des vidéos. Actuellement, il ne permet que de classer ces vidéos dans une ou plusieurs catégories et permet de mettre un lien vers le fichier.

De plus, j’ai introduit la notion de collection, vous pouvez donc créer des collections de vidéos (éventuellement protégée par mot de passe). Les vidéos ne sont visibles qu’à l’intérieur de la collection.

A termes, je compte essayer d’intégrer un lecteur vidéo dans le module pour lire directement les vidéos (vivement Java 7 ) et améliorer également les fonctionnalités du module.

Vous pouvez récupérer le module depuis l’interface de gestion des modules en allant dans la vue « Trouver plus de modules ».

Sinon, vous pouvez aussi directement le télécharger ici : ici

Ensuite, j’ai mis à jour le module films. Il est à présent possible de gérer des collections de films distinctes. Selon le même principe que pour le module de vidéos.

Vous pouvez directement le mettre à jour depuis l’application, ou le récupérer ici.

Et enfin, un peu moins cool

Je viens de mettre à jour le core de JTheque et plusieurs modules qui profitent maintenant des améliorations du core.

Ce sont surtout des refactorings au niveau et surtout au niveau du couplage entre les différentes couches de l’application.

Néanmoins, il est possible que certains modules ne fonctionnent plus avec cette version du Core

Si cela arrive, l’application est disponible ici avec tous les modules à jour.

Pour conserver les données actuelles, il suffit de décompresser la nouvelle application et d’y recopier tout ce que contient le dossier miniatures, le fichier config.xml et les fichier localhost.XXX et normalement, tout devrait fonctionner.

Voilà et désolé d’avance pour ceux qui auront des problèmes avec ma mise à jour

• Langage : Java 6.0
• Nom : ExtendedJFrame
• Version : 1.0
• Description : Cette api permet d’avoir plus de fonctionnalités sur des JFrame. Voir plus bas pour plus grande description.
• Nécessite : Java 6.0
• Licence : GPL
• Sources : Disponibles
• Documentation : http://baptiste-wicht.developpez.com/projets/extendedframe
• Téléchargement : http://baptiste-wicht.developpez.com/projets/extendedframe

Voilà ce que vous pouvez faire avec cette api : Tout d’abord, vous pouvez rendre cette ExtendedJFrame modale, c’est à dire qu’elle est bloquée et liée à une autre ExtendedJFrame. On ne peut rien faire sur la première fenêtre tant que la deuxième n’a pas été fermée. C’est le même principe que pour les Window.

Ensuite, vous pouvez bloquer la fenêtre et afficher une animation sur celle-ci. Deux animations sont directement disponibles dans l’API, une simple JProgressBar infinie et une deuxième animation en 2D plus complexe basée sur l’infiniteProgressPanel de Romain Guy. Tout ça, de manière très simple.

Enfin, vous pouvez réduire cette fenêtre dans le system tray (la zone de notification en général en bas à droite). C’est à dire que via un quatrième bouton à coté de réduire, vous pouvez rendre la fenêtre invisible et faire apparaître une icone dans le systray qui vous permettra de réouvrir votre fenêter plus tard.

Vous avez aussi une barre d’état directement sur votre fenêtre. De plus, j’ai essayé de rendre l’ExtendedJFrame le plus personnalisable possible. C’est à dire que vous pouvez utiliser votre propre barre d’état, votre propre barre de titre et voter propre figure d’attente. Il vous suffit juste d’implémenter les bonnes interfaces.

Normalement, tout ce qu’il est possible de faire avec une JFrame est possible avec ExtendedJFrame.

Pour vous faire une idée de comment ça marche, vous pouvez employer la classe Test, elle fournit 4 méthodes qui permettent de visualiser un peu tout ce qu’il est possible de faire avec ExtendedJFrame. Il vous suffit de choisir la méthode à lancer dans la méthode main.

Vous pouvez la télécharger sur la page de documentation.

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).