Archives de catégorie : Java

TestNG et ses DataProvider

J’aime beaucoup TestNG, et je l’utilise plutôt que JUnit depuis des années. D’abord, il s’agit d’un outil développé par un français, Cédric Beust, après tout, on a le droit d’être un peu chauvin ! Ensuite, j’ai toujours trouvé que les fonctionnalités offertes par ce framework étaient supérieures à JUnit, pourtant largement plus utilisé.

Cher et précieux lecteur, je te propose, dans cet article d’éviter de démarrer une nouvelle polémique dont le net est si friand, mais plutôt de te présenter une fonctionnalité particulièrement puissante de TestNG : les DataProvider.

Continuer la lecture de TestNG et ses DataProvider

Java 7 : le fork / join divise pour mieux régner

Dans la continuité de mes deux précédents articles, je voudrais aborder ici les bonnes approches de division en tâches dans le cadre du framework fork / join. Cela me permettra aussi de répondre ici à des questions envoyées par quelques précieux lecteurs (car oui, ce blog est lu par plusieurs personnes !). Le framework fork / join a pour objet de traiter de très grandes quantités de données, dans de très nombreuses tâches, tout en conservant le principe qu’une tâche doit effectuer un « petit » traitement. L’une des difficultés est de garantir que la quantité d’opérations réalisées par une tâche donnée reste limitée, et, surtout, n’augmente pas avec la taille globale du traitement.

Par exemple, dans un calcul matriciel, on ne veut pas que le temps de traitement d’une tâche dépende de la taille de la matrice à traiter.

Continuer la lecture de Java 7 : le fork / join divise pour mieux régner

Java 7 : plus loin dans le fork / join

La présentation du framework fork / join, objet de notre épisode précédent ne comportait qu’un seul exemple. Cet exemple était simple, mais non trivial tout de même. J’y avais glissé une remarque, que, précieux et averti lecteur, tu n’auras pas manqué de relever en te disant : « encore une remarque en l’air, qui tombe à plat, ces blogs techniques, tous les mêmes ! ».

Cette remarque est la suivante :

Chaque calcul et chaîne de calcul doivent être exécutés dans la même réserve, pour des raisons que nous verrons plus loin.

Eh bien nous y sommes, au « plus loin ». Je te propose, précieux lecteur, d’explorer plus avant les choses, afin qu’aucune zone d’ombre ne subsiste dans ce merveilleux framework.

Continuer la lecture de Java 7 : plus loin dans le fork / join

Java 7 : fork / join

Un précédent article, Synchronisation et volatilité, traitait de programmation concurrente, et de la façon dont le JMM (Java Memory Model), avait été entièrement réécrit en Java 5 (JLS v3). Il laissait complètement de côté l’API java.util.concurrent, nouveauté de Java 5, écrite par Doug Lea, et conçue à partir de l’API edu.oswego, disponible en Java 4. Cette API a subi quelques évolutions entre Java 5 et Java 6 , et en subit encore en Java 7.

C’est à un petit bilan de l’existant, et un rapide tour de table des nouveautés que je te convie aujourd’hui, cher et précieux lecteur. Je parlerai surtout du framework fork / join, et de la façon dont on peut l’utiliser. Pour une fois, dans Java le Soir, on va parler de l’avenir. Note bien, que, plus le temps passe, et plus l’avenir a tendance à devenir le passé, ce qui finira aussi par arriver à ce qui est écrit ici !

Continuer la lecture de Java 7 : fork / join

Les dessous de la sérialization – 2

Nous avions laissé notre héros au moment où il se rendait compte que cette merveilleuse API, la sérialization Java, pouvait tout faire elle-même, sans qu’il ait à se préoccuper d’autre chose que d’ouvrir un fichier ou une socket. En grattant un peu la surface, il s’est rendu compte qu’il pouvait personnaliser quelques aspects.

Mais il n’est pas au bout de ses découvertes, et en continuant son exploration, il va se rendre compte qu’il peut aller bien plus loin encore !

Continuer la lecture de Les dessous de la sérialization – 2

Les dessous de la sérialization – 1

La sérialization Java fait partie de ces mécanismes présents dès les premières versions du langage. Elle n’a subi qu’une seule modification majeure, depuis longtemps assumée par tout le monde. Elle fait également partie de ces mécanismes que l’on utilise sans même y penser, qui ont tendance à « marcher tous seuls », sans que l’on ait à s’en préoccuper. Il y a bien ce warning qu’Eclipse ne manque pas de nous coller lorsque l’on crée une classe sérializable sans déclarer de champ serialVersionUID. Mais finalement, il suffit de le créer et de lui coller une valeur au hasard pour que notre IDE préféré (quoique…) soit satisfait. Même plus besoin de connaître exactement le rôle de ce champ… Et quand bien même on ne le déclare pas, Eclipse continue de couiner, mais sans conséquence apparente sur le fonctionnement de notre application.

La sérialization Java permet de résoudre la plupart des problème qu’elle traite, de façon transparente, et sans avoir à connaître son fonctionnement interne. Finalement, n’est-ce pas ça la définition d’une API efficace ?

Le petit voyage auquel je t’invite à présent, précieux lecteur, va précisément nous mener dans les bas-fonds de cette API, de son fonctionnement interne, et des possibilités qu’elle offre, quasiment jamais utilisées. Un voyage inutile ? Peut-être, mais pour le savoir, il faut l’avoir fait !

Continuer la lecture de Les dessous de la sérialization – 1

Lumière sur les génériques – 2

Nous avions laissé nos héros au moment où ils allaient se rendre compte que List<Integer> n’était pas une extension de List<Number>. Emplis de désarroi, ils se tournèrent donc vers le type anonyme ?, qui va leur permettre de contourner ce problème. Même si ce chemin n’est certes pas exempt d’embûches, cela leur permettra au moins de terminer le tour d’horizon des génériques, commencé la semaine dernière.

Continuer la lecture de Lumière sur les génériques – 2

Lumière sur les génériques – 1

En ces périodes de restrictions de prestations sociales, utiliser les génériques est une recommandation classique. Ne reculant devant rien pour satisfaire à l’effort national de réduction des déficits, je me suis lancé dans cette mise en lumière, en me disant qu’il en sortirait bien quelques chose.

Les génériques, c’est un peu comme le vélo, ça a tendance à marcher tout seul. Et si ce n’est pas le cas, tout le monde sait qu’il est inutile de chercher à comprendre, et qu’il sera beaucoup plus efficace de bombarder son code de casts aléatoirement distribués jusqu’à ce que ça marche à nouveau.

Et puis, à un moment, malgré ce remède pourtant préconisé par le ministère de la Santé, ça déraille vraiment, et là on se retrouve les mains dans le cambouis, en se demandant ce qui a bien pu se passer.

Les génériques sont passés dans les mœurs depuis Java 5. L’impact a été énorme, puisque des centaines d’API ont été adaptées lors de leur introduction. Dans la plupart des cas, leur utilisation est naturelle, ce qui les rend très agréables à utiliser. Mais leur spécification recèle des mystères, et parfois des erreurs de compilation cryptiques apparaissent.

C’est à un petit voyage sous ces arcanes que je te convie, cher et précieux lecteur. Il ne nous mènera pas beaucoup plus loin que l’incomparable JLS, mais peut-être y découvriras-tu des paysages nouveaux ?

Continuer la lecture de Lumière sur les génériques – 1

Synchronisation et volatilité

Les deux notions de synchronisation et de volatilité sont en train de prendre, depuis quelques années, une importance croissante. La généralisation des processeurs multicœurs, jusque dans les téléphones portables, fait surgir des bugs dans les applications Java, qui ne s’observaient pas auparavant.

Nous avons de la chance, nous autres développeurs Java, pour deux raisons. La première, c’est que nous avons une doc, la JLS (Java Language Specification, nous vivons sous le règne de la v3), qui spécifie tous les aspects du langage. La deuxième, c’est que cette doc comporte un chapitre 17, qui traite précisément des problématiques de la programmation concurrente.

Nous avons aussi deux malchances. La première, c’est que la JLS est vraiment un document pénible à lire. Et la deuxième, c’est que le chapitre 17 est totalement hermétique. Finalement, traiter des problèmes complexes dans des documents illisibles a au moins un mérite : ça peut justifier l’écriture d’articles dans des blogs techniques.

Donc, ne reculant devant rien pour te satisfaire, précieux et intrépide lecteur, je te propose une petite explication de texte sur la synchronisation en Java, qui, je l’espère éclairera ta lanterne sur une problématique majeure du développement, actuellement et pour les années qui viennent.

Continuer la lecture de Synchronisation et volatilité

Bilan sur le pattern Singleton

S’il est un pattern sur lequel on ne cesse de revenir depuis son introduction par le célèbre GoF en 1994 dans Design Patterns: Elements of Reusable Object-Oriented Software, c’est bien celui-la. Entre les remarques sur le fait qu’il n’est pas thread safe, les différentes façons de lever ce problème, le fait qu’il utilise une variable statique, (ce que certains considèrent comme une hérésie), on n’en finit plus de faire la liste de ce qu’il faut faire ou ne pas faire.

Je voudrais tenter dans cet article de faire le bilan de toutes ces discussions, éparpillées à droite et à gauche sur le net, en y ajoutant un peu de réflexion personnelle. N’hésitez pas à me faire part de vos commentaires, et de vos retours d’expérience !

Continuer la lecture de Bilan sur le pattern Singleton