Blog de David MASCLET

Parfois nous devons exécuter un traitement et si le résultat est null nous voulons renvoyer un résultat par défaut. par exemple une liste vide. cela permet d'éviter les NullPointerExceptions si nous parcourons la liste. Exemple :

List<Contact> contacts = getContacts();
for (Contact contact : contacts){
      contact.setActive(true);
}

Si getContacts() renvoie null le code renverra une NullPointerException. il est possible avec les génériques Java de le faire d'une manière élégante :

 public static <T> T notNull(T test, T defaultvalue){
    return t == null ? test : defaultValue;
  }

On peut alors écrire :

List<Contact> contacts = notNull(getContacts(),new ArrayList<Contact>);

Ce code n'est pas révolutionnaire mais il montre à quel point les génériques de de Java peuvent être utiles. C'est d'ailleurs de cette manière que EasyMock fonctionne. Lorsque vous écrivez

Myclass mock = EasyMock.createMock(MyClass.class);
EasyMock.expect(mock.function()).andReturn(value);

Le type de value est déterminé en générique Java par le retour de function() :

 public <O> O expect(O t) {
        return t;
    }

Comme vous le savez déjà peut être, les sessions Hibernate sont très fortement couplées aux transactions : Hibernate ouvre et ferme les sessions au début et à la fin d'une transaction. Lors du développement d'une librairie (DAO), Je me suis posé la question "est il possible de ne pas utiliser un contexte transactionnel pour gérer les sessions ?". En effet lors de mes tests qui sont transactionnels, tout se passait bien mais lorsque j'intégrais mon code dans un contexte non transactionnel et que je tentais de récupérer des associations liées à une entité, j'avais des lazyInitializationException car les sessions était fermées. j'avais alors plusieurs solutions :

• Utiliser le filtre Spring Opensessioninviewfilter, mais cela rend ma librairie non portable car cela ne fonctionnera que dans un contexte web
• Faire des méthodes ad'hoc pour récupérer l'entité ou l'entité avec ses associations chargées (eager), mais au détriment d'un code moins lisible et où il est facile de ne pas utiliser la bonne méthode
• Charger les associations directement (par configuration) avec FetchType=Eager. pas assez performant !
• Utiliser les profiles de fectching
• Faire une gestion des session par thread.

Je vous propose de voir comment j'ai implémenté la dernière solution

Le cloud computing est un concept ou les applications sont exécutées par une puissance de calcul dont on ne gère plus l'infrastructure sous-jacente, on parle alors de puissance de calcul ou de stockage à la demande. Par analogie on peut comparer le cloud computing à la consommation électrique : on fait varier la production en fonction de la demande.

Souvent lorsque je parle de Gisgraphy, la question qui m'est posée est "quelles sont tes motivations" et "est-ce que tu gagnes de l'argent avec ce projet". Après leur avoir expliquer que le projet est open source et libre. La réaction est quasi toujours la même : "tu n'a pas peur que quelqu'un te pique le projet ? et comment peut on gagner de l'argent alors que tout est gratuit ?". J'ai donc décidé de faire ce billet pour expliquer mes motivations ainsi que les différentes façons de gagner de l'argent avec des projets open source et libres. autant vous le dire tout de suite : je perds de l'argent avec Gisgraphy, mais mon but n'est pas forcément d'en gagner (même si j'aimerais ne pas être de ma poche ;) )

Ceux qui ont déjà développé en C, puis en Java auront probablement apprécié la gestion de la mémoire par la JVM. En effet, Java masque la complexité de la gestion de la mémoire aux développeurs. Cette tache est déléguée au garbage Collector. Cependant même si cette gestion est dite 'automatique', cela ne permet pas de faire n'importe quoi. Que ce soit en C, Java, ou un autre langage, la mémoire est une ressource limitée ! En java lorsque la JVM n'a plus assez de mémoire pour s'exécuter, elle génère une Erreur java.lang.OutOfMemoryError.

Plusieurs cas sont alors possible :

• Soit vous n'avez pas alloué assez de mémoire à la JVM
• Soit votre code a ce qu'on appelle un fuite mémoire

Si vous êtes dans le premier cas, les choses se résolvent assez facilement : il vous suffit d'allouer plus de mémoire grâce aux paramètres -Xmx, -Xms et -XX:PermSize (ou de modifier le code pour qu'il gaspille moins de mémoire). Dans le deuxième cas vous allez devoir trouver où se situe la fuite mémoire. Si vous avez utilisé des logiciels pour vous y aider, vous avez peut être été perdu par toutes les possibilités qu'ils offrent et par la profusion d'informations qu'il fournissent.

Le but de ce billet est d'expliquer comment détecter et corriger les fuites mémoires avec Eclipse Memory Analyser Tool un outil gratuit et très utile qui aide vraiment à trouver les fuites mémoires. Nous allons voir comment extraire les informations pertinentes, les comprendre, et trouver les responsables des fuites mémoire en ayant une approche pragmatique. Je vous propose de nous appuyer sur du code simple (disponible en fichier attaché à ce billet) générant une fuite mémoire.

Certains connaissent peut être pastebin qui permet d'envoyer du code à quelqu'un (ou d'un PC à l'autre ;) ) en générant une shortURL. Il existe des sites qui vont plus loin en permettant de tester du code directement en ligne : http://codepad.org/. il suffit de copier / coller votre code, et le site vous le compile et vous l'interprète. c'est le cas de codepad

Il supporte les langages suivants :

• C
• C++
• D
• Haskell
• Lua
• OCaml
• PHP
• Perl
• Plain Text
• Python
• Ruby
• Scheme
• Tcl

Vous pouvez mettre votre code "privé", ce qui est pratique, car j'ai déjà retrouvé du code, que je ne voulais pas partager publiquement, indexé par Google, après l'avoir envoyé via pastebin)

Dans la même lignée, il existe des sites plus spécialisés pour tester les interactions HTML<=>Javascript : http://jsbin.com/. Son utilisation est triviale : vous avez le code javascript à gauche et le code HTML à droite.

Le site va beaucoup plus loin que pastebin, d'une part, car il est spécialisé dans un langage, mais aussi parce qu' il offre la possibilité :

• De sauvegarder votre code.
• D'inclure des librairies connues, comme Prototype, Jquery, Mootools, Dojo et de choisir parmi différentes versions
• De générer une short URL de votre code (exemple : http://jsbin.com/ilomu3)
• De modifier un code existant en cliquant sur ''Edit using JS Bin" en haut à droite (j'avoue c'est pas flagrant :) ).
• De gérer plusieurs versions d'un même code

L'avantage est qu'il permet de tester du code avant de mettre à jour un librairie (exemple : passer de Prototype 1.6.03 à 1.6.1.0), de vous faire la main sur des librairies, ou de partager du code entre collègues.

Après le billet consacré à JsUnit et celui qui expliquait comment mocker une requête Ajax, nous allons maintenant voir comment mocker en javascript. Pour cela je vous propose une courte présentation de JsMock. Les exemples de code sont en annexe de ce billet.