Java foreach.

Java — Tags :, , — admin @ 17:36

Java 5 got a bit closer to its twin C# by adding the possibility of directly accessing entities of a list or collection through its own “foreach” functionality :

C# :

  1. foreach(type var in arr){
  2.   // implement body
  3. }

Java :

  1. for (type var : arr) {
  2.     // implement body
  3. }

Bien implémenter son singleton

Java — Tags :, , , — admin @ 11:54

Lorsque plusieurs membres d’un programme vont utiliser les mêmes données, on se retrouve confronté au choix entre le singleton et la classe statique. Ce choix est assez important, et dépend entièrement de la visibilité de ces données. Il sera parfois plus judicieux d’utiliser une classe statique qu’un singleton. Par exemple, en programmant un jeu de tennis en C# (que je n’ai pas encore complètement terminé d’ailleurs…), j’avais besoin d’accéder souvent au calendrier ATP. La visibilité de ce calendrier était pratiquement globale, beaucoup de classes devaient y avoir accès et il était plus facile d’en faire une classe statique avec ses méthodes statiques… Dans d’autres cas, le singleton était plus approprié. Il n’est pas limité en accès aux membres statiques, il est sérializable, etc…

Récemment, en révisant du code sur un projet au boulot, je suis tombé sur des mauvaises implémentations de singletons de ce type :

  1. public class SinglePart {
  2.      private static SinglePart oPart = null;
  3.  
  4.      public static SinglePart getSinglePart() {
  5.          if (oPart == null){
  6.              oPart = new SinglePart();
  7.          }
  8.          return oPart;
  9.      }
  10.  }

La classe fonctionnait bien, puisque le programmeur avait fait attention à ne l’instancier qu’une seule fois. En fait, il y a 2 erreurs avec cette implémentation :

- Il manque un constructeur privé pour remplacer le constructeur public et donc éviter une autre instanciation via ce dernier.
- Rien n’assure que le singleton ne soit créé deux fois en même temps par deux threads séparés.

La solution consiste donc à ne pas oublier le constructeur privé, ainsi que l’utilisation du mot clef synchronized :

  1. public class SinglePart {
  2.      private static SinglePart oPart = null;
  3.  
  4.      // constructeur privé
  5.      private SinglePart() {}
  6.  
  7.      public synchronized static SinglePart getSinglePart() {
  8.          if (oPart == null){
  9.              oPart = new SinglePart();
  10.          }
  11.          return oPart;
  12.      }
  13.  }

Java : quelques bons réflexes à avoir (3)

Java — Tags :, — admin @ 23:00

Autre petit réflexe à avoir, et ceci ne se limite pas seulement au Java… La plupart du temps, on fait nos tests de manière simple et logique :

  1. if (sString.equals("machaîne")) {
  2.     // faire quelque chose
  3. }

ou encore…

  1. if (iNb == 2) {
  2.     // faire quelque chose
  3. }

La encore, un bon réflexe à avoir est d’inverser le test, de manière à comparer notre constante / chaîne à notre variable :

  1. if ("machaîne".equals(sString)) {
  2.     // faire quelque chose
  3. }

ou encore…

  1. if (2 == iNb) {
  2.     // faire quelque chose
  3. }

En effet, en prenant cette habitude, on ne lèvera jamais d’exception de type NullPointerException lorsque les variables sont mauvaises.

Java : quelques bons réflexes à avoir (2)

Java — Tags :, — admin @ 22:31

Dans la suite des évènements, je suis tombé sur de nombreuses conversions de types. Elles étaient bien sur contrôlées, ou du moins… La plupart étaient codées comme ceci:

  1. public int strToInt(String sString) {
  2.    try {
  3.       int iNb = Int.parseInt(sString);
  4.       return iNb;
  5.    } catch (Throwable t) {
  6.    }
  7. }

On pourrait croire que le code est juste. D’ailleurs, il marchait encore une fois très bien… Lorsqu’on lui demandait de faire ce qu’on attendait de lui. En fait, ce code peut être assez dangereux: si une exception est levée, il n’y a aucun moyen de le savoir, aucun avertissement pour dire que iNb n’a pas été initialisé correctement. Et si sString était nul?

Ce genre de problème se retrouve souvent, et j’ai malheureusement vu énormément de blocs try/catch vides, laissant au futur utilisateur un code ne marchant que dans certains cas…

La gestion des exceptions est quelque chose d’assez méticuleux en Java. On ne veut pas trop alourdir le code avec des nombreux blocs try/catch. Toutefois, ce genre d’erreur assez classique engendre facilement des problèmes par la suite. De nombreuses fois, le développeur mange les exceptions en laissant vide les blocs catch, un peu comme si ils avaient été créé un peu par hasard.

Il faut au moins enregistrer quelque part que l’exception a été levée (log d’erreur, message…). Le bon réflexe à avoir est bien sur de renvoyer l’exception.

Java : quelques bons réflexes à avoir (1)

Java — Tags :, — admin @ 18:09

Depuis peu de temps, je suis arrivé sur un projet J2EE pratiquement terminé. Mon but était de comprendre le fonctionnement de l’équipe, la structure du programme et du projet, d’en analyser les atouts et les défaillances. Pendant cette période, j’en ai profité pour regardé rapidement le code source. J’ai décidé de cataloguer les quelques petits problèmes que je voyais, tout en y apportant des solutions. Ce sont des petits reflexes à avoir lorsque l’on travaille en Java.

Attention au ramasse-miette

Demandez à n’importe quelle personne ayant travaillé en C/C++ et évolué sur du Java la chose qu’il a préféré, et cette personne vous répondra le ramasse-miette. C’est vrai qu’en C# comme en Java, le ramasse-miette est quelque chose d’exceptionnel, un aspect un peu magique qui rend la vie plus facile et le code plus souple. On n’a tout à coup plus à tenir compte de la gestion de la mémoire, ce qui peut représenter un énorme gain de temps, de production, et d’apétit le soir en rentrant chez soi.

Toutefois, le ramasse-miettes ne va pas s’occuper de tout. En effet, il existe des objets (pointeurs, poignées sur les fichiers, sémaphores, etc…) qui ont leur propres fonctions .close(), .destroy() ou .release() qu’il ne faut pas oublier d’appeller. Bien entendu, tout est automatiquement nettoyé par le dernier finalizer lorsque le programme se termine… Mais bien souvent, il vaut mieux s’en occuper de suite. (Imaginez un serveur multi-thread qui fait une fuite à chaque requête HTTP, la mémoire sera vite débordée…)

Ainsi, je suis tombé sur ce code:

  1. public static Properties loadFile(String sFileName) throws IOException {
  2.    FileInputStream sInputStream = new FileInputStream(sFileName);
  3.    Properties oProps = new Properties();
  4.    oProps.load(sInputStream);
  5.    sInputStream.close();
  6.    return oProps;
  7. }

Ce code compile parfaitement. De plus, l’application tournait aussi bien. Seulement, que se serait-il passé si la fonction load(sInputStream) avait relevé une exception? Le close() n’aurait pas eu lieu, et on aurait eu une fuite… jusqu’au dernier finalizer.

En fait, la solution consiste à utiliser un bloc try/finally pour vérifier que la fonction ne renvoie pas d’erreur :

  1. public static Properties loadFile(String sFileName) throws IOException {
  2.    FileInputStream sInputStream = new FileInputStream(sFileName);
  3.    try{
  4.       Properties oProps = new Properties();
  5.       oProps.load(sInputStream);
  6.       return oProps;
  7.    } finally {
  8.       sInputStream.close();
  9.    }
  10. }

Ainsi, le close() se fera toujours dans de bonnes conditions. J’avoue que cette pratique n’est pas très facile à mettre en oeuvre, surtout qu’elle risque facilement d’imposer la lourdeur des blocs try/finally imbriqués. On pourrait aussi revenir à une solution qui s’apparente au C/C++ et conserver quelque part une trace des différentes allocations mémoire pour les libérer manuellement, mais on perd l’intéret du ramasse-miettes… A méditer!

This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.
(c) 2012 Random namespace | powered by WordPress with Barecity