Mes premiers pas avec Android

Android est mon coup de cœur technologique du moment. Pour situer le concept rapidement, Android est le système d’exploitation de Google à destination des terminaux mobiles (Smartphone, PDA, …). La solution repose essentiellement sur deux grandes technologies : un noyau Linux et une machine virtuelle Java.

Mise en place de Maven sur des plugins Eclipse RCP

On n’a plus besoin de vanter les mérite de l’utilisation de maven et de l’intégration continue car ils ont fait leur preuves sur des applicatifs conséquents et cela commence être intéressant de les mettre en place même sur des “petits” projets.

Il est maintenant possible de gérer des projets type plugins Eclipse RCP avec Maven 2 et quelques plugins tierces. Certains diront “Et alors, on pouvait pas avant ?” Eh bien NON ! Enfin, pas depuis bien longtemps…

Intégration Continue

Un billet concernant quelque chose qui me tient particulier à coeur en tant que développeur.

L’intégration continue est un ensemble de pratiques liées au génie logiciel et qui permettent d’obtenir facilement un instantané de l’état d’un projet.

equals(Object o), hashCode() et Comparable

Vous avez sans doute déjà surcharger equals(Object o) ou hashCode() et réaliser compareTo(Object o) de l’interface Comparable. Mais saviez-vous qu’il existe un lien entre ces trois méthodes tout comme chacune d’elle doit avoir un comportement bien défini.

Optimisation de la mémoire de la JVM pour Eclipse

En voila un sujet qui fache !! La mémoire utilisée par Eclipse. Et c’est légitime que ce sujet déchaine les passions tant il est important de se pencher sur ce problème pour augmenter la productivité des utilisateurs eclipse.

En effet, avec une configuration par défaut, Eclipse est parfaitement adapté pour des projets simple de taille moyenne diront nous, cad sans dépendances complexes, sans avoir besoin de 1000 et 1 plugins et frameworks en tout genre.

Dès qu’il sagit de developper dans un environnement projet complexe (+ de 10 projets, + de 5 frameworks, RCP + WTP + Hibernate + Spring + Junit + BIRT + etc…) une configuration adaptée s’impose ! Car sinon on frole le drame ! Un environnement de développement instable et une machine qui “rame” comme jamais…
Symptomes: Des temps de chargement, de lancement, de build, de compilation ou de déploiement extrèmement longs et surtout une floppée de messages d’erreurs désagréables indiquant grossomodo qu’Eclipse manque de mémoire et vous incitant à redémarrer Eclipse (et la JVM par la même occasion).
Et quand on voit des popup “Eclipse need more memory… Do you want to exit the workbench now ? Yes. No.” ou des OutOfMemoryException toutes les 2 heures d’utilisation, il y a de quoi s’arracher les cheveux !!!
Car redémarrer Eclipse implique premièrement d’arreter la tache en cours, d’attendre 2 minutes qu’il redémarre puis accessoirement de relancer le serveur d’application en cours (environ 2 minutes) et de redémarrer le client RCP puis de se remettre dans la configuration avant le re-démarrage “forcé”… Environ 5 minutes de perdu seulement diront certains… mais a raison de 4 fois par jour, ca représente 20 minutes minimum par développeur au sein d’un équipe ! Charge non négligeable AMHA !

Premièrement, il n’y a pas de secret, dans une configuration complexe il faudra un minimum de 1Go de RAM, 2Go de préférence voir 3 à 4Go pour les plus gourmands ! (Ceux qui font de la médélisation UML + des jeux en LAN + Eclipse…) Sans oublier une machine performante tant au niveau processeur (Intel Core 2 Duo / AMD Athlon 64) que pour le reste…

Deuxièment, le lanceur Eclipse (raccourci ou bat ou cmd) doit comporter des arguments spécifiques à la JVM pour paramètrer l’utilisation de la mémoire vive. Pour cela on peut ajouter le paramètre “-vmargs” suivi de propriétés à passer à la machine virtuelle java.

Pour info, dans “vmargs” on trouve “vm” soit “virtual machine” et “args” soit “arguments”… rien de bien compliqué.

Ensuite les propriétés que l’on peut passer à la machine virtuelle dépendent de votre configuration matérielle et de votre utilisation d’Eclipse… Voici des préconisations qui correspondent à un besoin particulier (le mien)… à vous d’adapter et de tester si cela vous convient au mieux ou pas.

On a pour habitude d’utiliser la propriété “-Xmx256m” pour augmenter la mémoire maximum utilisable par la JVM (Mx = Max et 256m = 256Mo de mémoire) mais il y est des cas ou cela ne suffit pas comme vu ci dessus.

Il est aussi possible de spécifier à la JVM la mémoire minimum allouée par la propriété “-Xmx256m” par exemple.

Et pour finir on peut imposer la taille du permGen Space* avec les propriétés “-XX:PermSize=64m” et “-XX:MaxPermSize=64m” par exemple, respectivement la taille par défaut allouée pour le permGen Space et sa taille maximum. (* terme défini et expliqué à la fin de cet article)

EDIT: Après étude, il faut ajouter “-XX:+CMSPermGenSweepingEnabled -XX:+CMSClassUnloadingEnabled” à la liste des paramètres afin d’autoriser le garbage collector à décharger des classes dynamiquement et de nettoyer les objets…

Toutes ces propriétés combinées permettant d’optimiser la gestion de la mémoire par la JVM en charge de faire fonctionner Eclipse ! Ce ne sont pas les seules existantes… mais les seules dont on parle dans cet article.

Voici quelques préconisation fonction de la mémoire RAM de votre machine.

Pour 512Mo de Ram: -vmargs -Xms256m -Xmx256m -XX:PermSize=64m -XX:MaxPermSize=64m -XX:+CMSPermGenSweepingEnabled -XX:+CMSClassUnloadingEnabled

Pour 1Go de Ram: -vmargs -Xms512m -Xmx512m -XX:PermSize=128m -XX:MaxPermSize=128m -XX:+CMSPermGenSweepingEnabled -XX:+CMSClassUnloadingEnabled

Pour 2Go de Ram: -vmargs -Xms768m -Xmx768m -XX:PermSize=256m -XX:MaxPermSize=256m -XX:+CMSPermGenSweepingEnabled -XX:+CMSClassUnloadingEnabled

Après, n’ayant pas testé les configurations supérieures à 2Go, il vaut mieux ne pas se mouiller ! Chacun son opinion sur la question… on a tous des sensibilités différentes quand aux réactions de sa machine.

Qu’est ce que le heap space de la JVM:
Les propriétés -Xms768m et -Xmx768m permettent de spécifier la taille du heap space de la JVM, la taille de la mémoire utilisée pour faire vivre les objets java, la taille du dépot où sont stockés les objets en vie, les objets morts et la mémoire libre. C’est le Garbage Collector (GC) de la JVM qui s’occupe de nettoyer tout ca en fonction de la taille allouée à la mémoire. Un objet inutilisé (aucun pointeur (variable) qui y fait référence) est théoriquement supprimé de la mémoire par le GC quand celui ci se charge de nettoyer la mémoire.

Qu’est ce que le permGen space de la JVM:
Spécifique à la JVM Sun, cette zone mémoire contient tout ce qui n’est pas géré par le GC; tout ce qui est relatif au classes (leur structure: méthodes, champs, annotations…), les champs static, les chaines littérales… On spécifie le permGen space avec les propriétés -XX:PermSize=256m et -XX:MaxPermSize=256m par exemple. Plus on a de classes différentes plus il faut augmenter la taille de cette zone mémoire.

-XX:+CMSPermGenSweepingEnabled -XX:+CMSClassUnloadingEnabled ?

Ressources:
http://www.eclipsezone.com/eclipse/forums/t61618.html
http://edocs.bea.com/wls/docs61/perform/JVMTuning.html
http://www.developpez.net/forums/showthread.php?t=438282
http://java.sun.com
http://java.sun.com/javase/technologies/hotspot/gc/gc_tuning_6.html
http://java.sun.com/docs/hotspot/HotSpotFAQ.html
http://java.sun.com/performance/reference/whitepapers/6_performance.html
http://wiki.eclipse.org/FAQ_How_do_I_increase_the_permgen_size_available_to_Eclipse%3F
etc…

Eclipse-BuddyPolicy: registered et Eclipse-RegisterBuddy: com.provider.team.project

Eclipse-BuddyPolicy: registered et Eclipse-RegisterBuddy: com.provider.team.project

Aie cet article commence directement par des insanités de configuration… On va tenter d’expliquer tout ça !

Le but étant de répondre à la question : comment configurer les plugins eclipse pour permettre à un plugin d’accéder aux “classpath” d’un autre plugin qui est dépendant du premier plugin.

Si vous avez un plugin 1 et un plugin 2 avec le plugin 1 qui dépend du plugin 2 et par exemple un accès aux ressources du plugin 1 par le plugin 2… oui oui c’est incompréhensible mais c’est possible comme situation !

Par exemple, en ce qui concerne la gestion des fichiers ressources. Vous avez une classe Bundle1 dans le plugin 1 qui se charge d’accéder au fichier bundle1.properties se trouvant aussi dans plugin 1. Cette classe étend AbstractBundle dans le plugin 2 qui est un facilitant pour coder des classes d’accès aux fichiers ressources. Toutes les méthodes d’accès au fichier de ressource se trouvent dans AbstractBundle et pourtant le plugin 2 n’a pas accès aux ressources du plugin 1 car la dépendance va dans l’autre sens… Et donc pendant l’exécution vous avez des erreurs types filenotfound ou autre.

On peut aussi très bien avoir le même problème pour des accès à des classes à la place des fichiers ressources et le problème est le même. Un plugin ne sait pas accéder au classpath des plugins qui dépendent de lui, il faut le configurer pour cela.

Dans ce cas précis, il faut spécifier au plugin 1 quels sont les plugins qui sont autorisés en ajoutant dans son MANIFEST.MF la ligne suivante:

Eclipse-RegisterBuddy: com.provider.team.plugin2

Avec com.provider.team.plugin2 qui correspond à l’ID du plugin 2.

Puis dans le MANIFEST.MF du plugin 2 il faut spécifier la politique de gestion du classloading en ajoutant la ligne:

Eclipse-BuddyPolicy: registered

Ce qui signifie que seuls les plugins s’enregistrant comme autorisant le plugin 2 à accéder à leur classpath seront accessibles par le plugin 2… Ouf !

Certains diront qu’il suffit de mettre une dépendance du plugin 2 vers le plugin1 pour résoudre le problème mais les dépendances cycliques ne sont pas recommandées et surtout ce n’est pas forcément possible car le plugin 2 peut très bien être un plugin de type framework/utilitaire (log4j, spring, hibernate etc…) et on ne va pas modifier une plugin de ce type pour lui spécifier tous les plugins auxquels il peut accéder.

Références:
http://wiki.improve.fr/wiki/moni/trucs
http://help.eclipse.org/help32/index.jsp?topic=/org.eclipse.platform.doc.isv/reference/misc/bundle_manifest.html
http://www.ibm.com/developerworks/library/os-ecl-osgi/index.html (Buddy class loader options)
et Google

Méthodes avec types paramétrés

Depuis Java 5.0 nous avons la possibilité d’utiliser les types paramétrés. En plus de nous éviter de devoir caster chaque type de sortie d’une liste, cette amélioration nous permet également de créer des méthodes utilisant cette fonctionnalité.

L’exemple le plus connu est surement celui de javax.swing.event.EventListenerList et de sa méthode getListeners(Class<T> t) qui nous retourne un tableau d’objet de type t .

Comment écrire une méthode au comportement similaire ?

Qu’est-ce qu’un POJO ?

POJO est tout simplement un acronyme de “Plain Old Java Object” et fait référence à un objet Java simple indépendant de tous autres composants. Le but du POJO est de simplifier au maximum la création d’objets dans une application Java.