vendredi 4 avril 2008

Veille technologique semaine 14

Je vous propose quels articles pour cette semaine (avec ou sans un poisson d'avril ? A vous de vérifier).

  • un premier sujet sur la non mutabilité (immutabilité) des objets en Java : comment supprimer les bugs de modification non souhaité des objets passés en paramètres des opérations. Le MIT propose le JSR 308 avec (entre autre) @ReadOnly pour indiquer la non mutabilité. Cette évolution du langage est essentielle car il est indispensable de préciser dans les interfaces des composants (services ou évènements), un contrat sans aucune ambiguïté sur les arguments en in (en entrée) : en lecture pour l'appelé, en out (en sortie) : en écriture pour l'appelé, ou en in out. C'est une notion proche du const du C / C++. La proposition du MIT doit être intégré dans le JDK 7. Cela va donc être une migration obligatoire.
    Question
    : comment gérer vous actuellement cette notion d'arguments in, out ou in out dans les opérations de vos interfaces ? Comment spécifier vous ces notions ? Comment les vérifiez vous en test unitaires ? Je suis très intéressé par vos réponses.
  • des articles sur le principe d'un langage spécifique (DSL : Domain Specific Language) en Java pour les assertions de JUnit : les matchers de hamcrest également utilisé par JMock. C'est très puissant et très agréable à utiliser. C'est la raison de passer à JUnit 4.4 pour le assertThat() et à JMock 2.4 pour les expectations
  • les prochaines présentation du club d'utilisateur Java sur Paris avec une présentation (en anglais) sur la programmation concurrente et les performances.
  • la machine virtuelle Java est-elle lente : des petits tests qui montre que la pratique est conforme à la théorie : le compilateur dynamique JIT (Just In Time) donne des meilleurs résultats que la compilation statique (appelé parfois compilation native) AOT (Ahead Of Time).

Bonne lecture.



A Practical Type System and Language for Reference Immutability
What code may modify a data structure? Under what circumstances? Currently, inadequate language support for:

  • documenting immutability
  • verifying immutability


  • Argument immutability
  • Return value immutability
  • Object immutability
  • Benefits of immutability constraints


Simplifier les assertions JUnit et améliorer vos tests
Nombreux sont ceux d'entre nous qui ont déjà utilisé JUnit pour écrire des tests.
Quel est celui qui n'a pas été déçu par les limitations inhérentes aux différentes méthodes assertXXX() ?
Quel est celui qui n'a pas utilisé des librairies supplémentaires (JUnit-addons, Unitils, ...) contenant des
méthodes utilitaires du type assertContains, ... ?
Quel est celui qui n'a pas écrit sa propre méthode utilitaire ?
Si vous vous sentez concernés, lisez la suite de cet article qui aborde :

  • Les limites et défauts de JUnit
  • Les solutions classiques
  • Une solution magique

Flexible JUnit assertions with assertThat()


The Hamcrest Tutorial
Introduction
Hamcrest is a framework for writing matcher objects allowing 'match' rules to be defined declaratively. There are a number of situations where matchers are invaluble, such as UI validation, or data filtering, but it is in the area of writing flexible tests that matchers are most commonly used. This tutorial shows you how to use Hamcrest for unit testing.


Literate Programming with jMock


Prochaines réunions Paris JUG (Java User Group)


Les performances Java : mardi 8 avril 2008
19h à 19h15 : Accueil
19h15 à 20h30 : Les performances Java
*** La présentation est en anglais ***


La machine virtuelle Java est-elle vraiment lente ?
Le code natif n'est pas forcément plus rapide que du bytecode, et que cela pouvait même être l'inverse puisque les JVM actuelles utilisent un compilateur JIT.

Lorsqu'on compile un code natif, les compilateurs n'activent pas toutes les optimisations possibles afin que le programme puisse s'exécuter sur des machines ne disposant pas forcément du même type de matériel (et particulièrement le CPU).

A l'inverse, le bytecode Java est compilé dynamiquement à l'exécution par le compilateur JIT. Ce dernier peut donc prendre en compte les spécificités de la machine. Le gain de performance peut être très important...

Conclusion
Le code natif ne se révèle pas forcément plus rapide que le bytecode Java puisqu'il ne peut pas bénéficier de toutes les optimisations possibles du matériel à moins de procéder à une compilation spécifique. Il peut toutefois être plus performant que la JVM Client dans certain cas, reste à savoir si le gain de performance est vraiment aussi important sur une application cliente...

Dans bien des cas la JVM Server se montre la plus performante puisqu'elle profite au maximum des spécifités de la machine. Toutefois pour des applications normales (c'est à dire qui ne se contentent pas d'effectuer la même opération 100 millions de fois), le gain ne sera pas forcément aussi évident...

Concernant le mode interprété, il semble plus qu'évident qu'il est à l'origine du mythe sur la lenteur de Java, mais cela n'a plus rien à voir avec les JVM actuelles...