Les pages JDBC viennent d’être mises à jour. Peu de changements au programme, mises à part la navigation et la présentation.
Tous les articles par José
Mise à jour d’Introduction à SQL
Les pages Introduction à SQL viennent d’être mises à jour. Au programme quelques ajouts, quelques coquilles de moins, et une nouvelle façon de naviguer dans les pages, plus simple, du moins je l’espère.
Ouverture d’une section tutoriaux
Java le soir s’enrichit d’une nouvelle section Cours & tutoriaux, qui ouvre avec un premier pas à pas permettant d’utiliser Derby dans Eclipse. Il s’adresse surtout à des débutants, qui connaissent déjà un peu Eclipse, et qui souhaitent l’utiliser pour interagir avec leur serveur de base de données favori (à condition que ce soit Derby).
Il y aura d’autres tutoriaux sur différents sujets, certains sont déjà en préparation.
Petite note : je me suis fait un peu plaisir avec les CSS, et j’ai pu voir que certains navigateurs n’affichaient pas la page correctement. Donc si vous trouvez le texte illisible (visuellement), une bonne solution est de mettre à jour votre navigateur ! Si vous lisez ces pages c’est que vous devez être un peu intéressé par les nouvelles technologies. Traîner sur le net avec un vieil IE 6, ça fait un peu désordre…
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.
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 !
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 !
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 !
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.