Je viens de passer ce matin la certification SCJP pour Java SE 6.0. Et j’ai réussi à passer le test

J’ai réussi le test avec 93%

Ca fait plaisir de voir que les efforts paient.

Pour passer cet examen, je me suis entièrement basé sur « Sun Certified Programmer for Java 6 Study Guide » de Kathy Sierra et Bert Bates que j’ai lu deux fois.

J’ai également bénéficié de l’initiative de SAI pour obtenir des vouchers à 40$ pour les étudiants.

Voilà

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.

Plusieurs nouveautés majeures sont au menu :

• Analyse d’architectures. L’architecture des projets est maintenant analysée, on peut voir également une matrice des dépendances d’un projet ainsi qu’une liste des dépendances qu’il faudrait supprimmer.
• Analyse orientée object : Nouvelles métriques pour la qualité de la conception orienté objet
• Améliorations au niveau de l’interface graphique

Bref, que du bon

Je n’ai pas encore testé cette nouvelle version, je vais attendre que mes plugins soient compatibles avec les nouveautés, mais je n’hésiterai pas à faire des retours une fois installée.

Plus d’informations sur le site de Sonar.

Une petite nouvelle pour l’avancement du projet JTheque.

J’ai commencé à migrer JTheque Core vers un environnement OSGi et Spring Dynamic Modules. Le core sera désormais séparés en plusieurs bundles par fonctionnalité.

Les modules seront aussi des bundles OSGi.

Ce changement permettra d’améliorer la modularité des différents éléments du core et de suivre une voie plus standarde pour la création de modules.

J’espère que cela permettra d’améliorer la qualité de JTheque Core. C’est également une occasion pour moi d’apprendre à utiliser OSGi et Spring DM.

Baptiste

I’m happy to announce an other article of mine in English : The reserved keywords of the Java Language

This article will list all the java keywords and describe what they do and how to use them.

je viens d’écrire un nouvel article : Journalisation avec SLF4J.

Cet article va vous montrer comment utiliser SLF4J dans votre projet. SLF4J est une couche d’abstraction de journalisation à l’image de Commons Logging, mais avec plusieurs avantages par rapport à ce dernier. Ces avantages sont tous décrits dans l’article ainsi que les différentes fonctionnalités de cette librairie.

J’espère que cet article vous intéressera.

Baptiste

SLF4J is an abstraction layer for logging frameworks. The way is almost the same as Commons Logging but this framework solve the little issues existing with Commons Logging like the implementation loading with classloader or memory leaks. And introduce also a simpler way to log with heavy concatenations.

I hope this article will be useful for some of you.

I wrote a new article about JR : Introduction to JR programming language.

This article will introduce you to the main concepts of JR :

• Compile and launch JR programs
• Declare process in JR
• Declare quiescence action
• Use semaphores to solve critical section problems

I hope this article will be useful to some of you.

J’ai écrit ce mois-ci quelques articles qui pourraient vous intéresser.

Deux de ces articles concernent le langage de programmation JR qui est une surcouche de Java permettant de faciliter la gestion de concepts de programmation concurrente (sémaphores, CCR, moniteurs, …) :

• Installer l’environnement JR sous Windows
• Introduction au langage JR

Ensuite de quoi, j’ai également écrits 2 articles sur les services de Google, Friend Connect et Analytics :

• Analyser l’audience de votre site web avec Google Analytics
• Développer une communauté autour de votre site avec Google Friend Connect

J’espère que ces articles vous intéresseront

Au premier abord, cela peut être tentant étant donné qu’on gagne 2 octets (c’est toujours ça). Alors pourquoi utiliser un int alors qu’un short suffirait ?

Mais quand on y réfléchit, on voit bien que le int est le plus adapté. Il est en effet plus performant.

Pourquoi ?

En Java, toutes les opérations mathématiques sur des nombres entier (++ par exemple) se font en int. De ce fait, si on utilise un short comme indice de boucle, il faudra à chaque itération, effectuer un type casting implicite vers short, ce qui est plus couteux qu’une affectation directe vers int.

Pour appuyer mes propos, j’ai développé un petit test :

Qui me donne comme résultat :

Temp pour int : 1441 ms
Temp pour short : 3015 ms

La version avec short est donc deux fois plus lente !

Je parle ici des boucles for, mais le cas est le même lorsque vous utilisez une boucle while qui garde un indice et qui l’incrémente à chaque tour.

On peut relativiser en disant qu’ici on fait 100’000 fois 32’760 itérations et on ne perd qu’une seconde et demie. Néanmoins, dans des endroits critiques, on peut chercher à gagner le moindre nombre de millisecondes (voire nanosecondes).

Le short sera toutefois à privilégier dans le cas d’un stockage de données de petite taille.

A noter également que le int est à priviligier aux long, double et float pour les indices de boucle pour les mêmes raisons que le short. La version long est environ 3 fois plus lente et les versions double/float sont 2.5 fois plus lente.

En conclusion, utilisez toujours des int comme indices de boucle.