Deux problèmes assez courant peuvent survenir sur les connections à une base de donnée Oracle. Ces problèmes peuvent être à l’origine de timeout sur les connections HTTP, etc…

Ces deux problèmes touchent deux choses totalement différente, l’entropie du système et la coupure de connection par un firewall.

Entropie

Pourquoi l’entropie ? L’entropie est une mesure de l’incertitude d’un message par rapport à celui qui le précède. Sur un système POSIX c’est /dev/random qui est mesuré avec l’entropie. Hors la JVM utilise ce device pour la génération de nombres aléatoires utilisable pour des fonctions cryptographique, SecureRandom.

Hors le driver Oracle 11g (possiblement dans les versions précédentes aussi) établie un lien sécurisé avec la base donnée pour protéger les échanges de credentials.

Le problème vient du fait que la lecture dans /dev/random est bloquante tant que le système (Linux, BSD, etc.) considère qu’il n’y a pas assez d’entropie. Heureusement en bon lecteur de la javadoc il y a une note sur SecureRandom.

Note: Depending on the implementation, the generateSeed and nextBytes methods may block as entropy is being gathered, for example, if they need to read from /dev/random on various unix-like operating systems.

La MAUVAISE solution

Java permet de changer la source du random avec la propriété java.security.egd, si on prend le device/dev/urandom. Ce device à l’inverse de /dev/random est non bloquant. Donc sur la ligne de comande il suffirait d’ajouter cette option pour s’en sortir ?

-Djava.security.egd=file:/dev/./urandom

Non surtout pas. Pourquoi ce n’est pas une bonne solution ? Le soucis ici est qu’on abaisse le niveau de sécurité de la JVM. Que ce soit pour l’établissement de connexion à Oracle ou une connexion HTTPS, la sécurité est compromise. Comme il n’y a plus assez d’entropie un attaquant peut connaitre ou determiner quel sera les prochains nombres qui sortiront de SecureRandom et donc potentiellement reconstruire les éléments cryptographiques tel que les clé privé, à partir de là l’attaquant à les mains libres.

Ce qu’il faut faire

Les OS alimente /dev/random généralement à partir de plusieurs sources, comme les sonde de température, l’activité du CPU, le trafic réseau, mais cela s’avère parfois pas assez efficace. L’idée est donc d’aider l’OS. Installer un démon qui ajoute de l’entropie au système. Il en existe plusieurs, celui que j’utilise est HAVEGED ; il utilise les états des composants internes des processeurs modernes pour augmenter significativement l’entropie du système. À noter il tourne dans le user space donc assez facile à installer.

Avec un Firewall

Suivant les infra et les besoins de légalité, il faut protéger les bases de données par un firewall. Le firewall va inspecter et protéger les équipements derrières mais il fait aussi de l’assainissement des connections TCP, il va couper les connections inactive au bout d’un certain temps.

Avec le pool de connection

En général quand on fait du connection pooling sur des connections longues (typiquement le rôle d’une Datasource) ça n’arrange pas les choses. Quand le pool donne une connection il ne sait pas forcement qu’elle à été fermé par un composant tierce (un firewall). Heureusement c’est un simple manque de configuration, il n’y a qu’à lui dire de vérifier les connections régulièrement par exemple tomcat-jdbc :

• minEvictableIdleTimeMillis : The minimum amount of time an object may sit idle in the pool before it is eligible for eviction. The default value is 60000 (60 seconds).
• timeBetweenEvictionRunsMillis : The number of milliseconds to sleep between runs of the idle connection validation/cleaner thread. This value should not be set under 1 second. It dictates how often we check for idle, abandoned connections, and how often we validate idle connections. The default value is 5000 (5 seconds).

A simple example of a datasource configuration to be adapted to your infrastructure settings.

<Resource name="Locator"
      type="javax.sql.DataSource"
      factory="org.apache.tomcat.jdbc.pool.DataSourceFactory"
      testOnBorrow="true" driverClassName="oracle.jdbc.OracleDriver"
      validationInterval="30000"
      validationQuery="SELECT 1 FROM DUAL"
      ...
      timeBetweenEvictionRunsMillis="30000"
      minEvictableIdleTimeMillis="60000"
      url="jdbc:oracle:thin:@..."
      ...
      >
</Resource>

Certains pool offrent une configuration plus fine et peut-être plus sûre comme HirakiCP. Mais c’est hors propos. Quoiqu’il en soit cette option n’est pas optimale car elle ne traite pas le problème à sa source.

jdbc:oracle:thin:@(DESCRIPTION=(ENABLE=BROKEN)(ADDRESS=(PROTOCOL=tcp)(PORT=1521)(HOST=myhost))(CONNECT_DATA=(SID=orcl)))

$ cat /proc/sys/net/ipv4/tcp_keepalive_time 
2400 
$ cat /proc/sys/net/ipv4/tcp_keepalive_intvl 
75 
$ cat /proc/sys/net/ipv4/tcp_keepalive_probes 
6

Voici un petit exemple code qui utilise le SchemaExporter de hibernate. Le code est bien sûr à adapter à la structure du code de l’application.

Le principe est de passer soit même les classes annotées ET les package annotés (typiquement par @TypeDef dans le package-info.java). Pour plus de commodité ce code utilise le framework Reflections pour scanner les classes annotées par les annotations JPA @Entity et @MappedSuperClass. Par défaut le script génère les drop statements, mais ce comportement peut se changer à travers les options de SchemaExport.

import javax.persistence.Entity;
import javax.persistence.MappedSuperclass;
import org.hibernate.cfg.AvailableSettings;
import org.hibernate.cfg.Configuration;
import org.hibernate.tool.hbm2ddl.SchemaExport;
import org.hibernate.tool.hbm2ddl.Target;
import org.junit.Test;
import org.reflections.Reflections;

public class HibernateDDLGenerator {

    public static final String ENTITIES_PACKAGE = "com.something";
    public static final String ANNOTATED_PACKAGE = "com";
    public static final String HBM_DIALECT = "org.hibernate.dialect.Oracle10gDialect";

    @Test
    public void ddl() throws Exception {
        new SchemaExport(createHibernateConfig())
                .setOutputFile("/tmp/ddl.sql")
                .setFormat(true)
                .setDelimiter(";")
                .create(Target.EXPORT);
    }

    private Configuration createHibernateConfig() {

        Configuration conf = new Configuration();

        final Reflections reflections = new Reflections(ENTITIES_PACKAGE);
        reflections.getTypesAnnotatedWith(MappedSuperclass.class).forEach(conf::addAnnotatedClass);
        reflections.getTypesAnnotatedWith(Entity.class).forEach(conf::addAnnotatedClass);

        conf.addPackage(ANNOTATED_PACKAGE) // contains @TypeDefs
            .setProperty(AvailableSettings.DIALECT, HBM_DIALECT);
        return conf;
    }
}

gist : https://gist.github.com/bric3/370654ecad0eb81aca22

Du coup je lance jvisualvm depuis mon terminal (celui du JDK7 update 7). Là j’ai la liste des process java qui tournent malheureusement quand je choisi d’investiguer ce process, jvisualvm me rapporte sur le terminal :

attach: task_for_pid(7234) failed (5)

L’onglet du process s’ouvre bien dans jvisualvm mais impossible monitorer les threads ni faire de heap dump (au cas ou ça m’intéresserai), d’ailleurs ces sous-onglets ne sont même pas affiché.

La solution: passer avant au process java qu’il faut monitorer les paramètres suivants (en fonction des besoins)

• -Xverify:none : Désactive la vérification du bytecode dans la JVM. De base la JVM s’assure que le bytecode vérifie certaines règles. Bref il faut activer ce flag si vous voulez faire des thread dump ou des heap dump. Il s’agit probablement d’un bug du JDK7 ou de jVisualVM sur OSX.
• -Xshare:off : Comme son nom l’indique il s’agit de partager de la mémoire, dans les faits ça se traduit par le partage des classes déjà chargé. Sur mac cette option est active par défaut. A priori cette option pose problème pour l’attachement à un process Java, du coup en isolant la mémoire du process on peut s’en sortir.
• -Dcom.sun.management.jmxremote : Active l’export des MBean de la JVM, si vous voulez les monitorer

On dirait une réapparition dans le JDK7u7 d’un bug a priori déjà clos dans le JDK6 (pour OSX). A noter que les outils en ligne de commade tel que jmap peuvent aussi être affectés.

Bien entendu si j’ai loupé un truc je suis tout ouïe.

Référence : http://java.net/jira/browse/VISUALVM-326

Dans les news récemment

• Guava 13.0 réduit la consommation en mémoire de plusieurs structures [source]
• J’ai passé des tests d’algorithmie [source]

Premier point, on sait que Google est attentif sur les performances de ses librairies. Sur le deuxième point, ben j’ai finalement loupé un des exercices “timeboxés”, je n’ai pas eu le temps de le finir a temps, du coup le code soumis était 100 % foireux. Mais bon ce n’est pas le sujet du billet, ce qui est important c’est que j’ai fini après cet algo, puis je me suis rendu compte que celui-ci n’était pas optimal, il ressemblait à un algo en O(n²) O(n log n) (Merci Sam pour cette correction). Du coup j’ai repris le papier et le crayon, et je me suis rendu compte que je pouvais utiliser une technique similaire à celle que j’ai utilisé sur le premier algo du test (comment n’ai-je pas pu y penser à ce moment d’ailleurs ?).

De mémoire l’algo porte grosso modo sur le comptage de paires d’entier distante d’un nombre K dans un tableau A.

Ma première version :

class PairCounts_V1 {
    public int countPairsWithKDistance(int K, int[] A) {
        if(A == null || A.length < 2) return 0;

        Arrays.sort(A);

        int paircounter = 0;

        int j = A.length - 1;
        for (int i = 0; i <= j; i++) {
            int val_i = A[i];

            for(; i<j && K - A[j] != val_i; j--);
            int val_j = A[j];

            if ((long) (val_i + val_j) == K) {
                paircounter = incrementPairCounter(paircounter, i, j);

                // count duplicates
                while(val_j == A[--j]) paircounter =
                              incrementPairCounter(paircounter, i, j);
            }
            j = A.length-1;
        }

        return kpaircounter;
    }

    private int incrementPairCounter(int paircounter, int i, int j) {
        paircounter++;
        if(i != j ) paircounter++;
        return paircounter;
    }
}

Alors pourquoi je pense que cet algo n’est pas optimal : simplement du fait des boucles inbriquée, on dirait du O(n²) O(n log n) (voir ici pourquoi). Mais quand on parle de la performance ou de la complexité d’un algorithme il ne faut prendre uniquement compte de l’invariant mais aussi du jeu de données : quelle taille ? quelle distribution ? quel type de données ?

En effet un algorithme pour être efficace doit être adapté aux jeux de données qu’il aura à traiter et à l’usage qu’on en a ; peut-être à travers des paramètres ou des structures différentes, typiquement un des constructeur d’une HashMap prend des paramètres comme le facteur de charge et la taille initiale, on pourra choisir une TreeMap au lieu d’une HashMap si la recherche est un cas d’utilisation de la structure de donnée.

Bref du coup voilà à quoi ressemble la nouvelle version de cet algo :

class PairCounts_V2 {

public int countPairsWithKDistance(int K, int[] A) {
        if(A == null || A.length < 2) return 0;

        HashMap<Long, Integer> complements = new HashMap<Long, Integer>();
        for (int number : A) {
            long complement = K - number;

            Integer complementCount = complements.get(complement);
            complementCount = complementCount == null ?
                                  Integer.valueOf(1)
                                  : ++complementCount;
            complements.put(complement, complementCount);
        }

        int paircounter = 0;
        for (int number : A) {
            Long key = Long.valueOf(number);
            Integer complementCount = complements.get(key);
            paircounter = complementCount == null ?
                              paircounter
                              : paircounter + complementCount;
        }

        return paircounter;
    }

}

Donc ici l’idée c’est de préparer dans un premier temps un dictionnaire  inversé basé sur un des entier et la distance demandée, en incrémentant pour chaque occurence. Ici une seule boucle for, car on parcours en entier le tableau. Dans un second temps on cherche les entiers qui correspondent effectivement à l’entrée de ce dictionnaire, et si oui on incrémente le compteur de paires. Là aussi une seule boucle sur le tableau donc O(n). Sachant qu’une HashMap a souvant une complexité de O(1) pour l’insertion et la recherche, a vue de nez l’algo est plutot pas mal.

Bon mais dans la réalité ca donne quoi, en effet comme Kirk Pepperdine et bien d’autres disaient : Measure ! Don’t guess !

Caliper me voilà !

Caliper est un outil codé par des personnes de chez Google, il est notamment utilisé par l’équipe en charge de Guava. On peut d’ailleurs voir dans les sources de Guava les benchmarks ici par exemple.

Avec un projet “mavenisé” on récupère la dernière version de caliper, la version 0.5-rc1 aujourd’hui.

<dependency>
    <groupid>com.google.caliper</groupid>
    <artifactid>caliper</artifactid>
    <version>0.5-rc1</version>
</dependency>

Pour écrire un benchmark caliper il suffit d’étendre la classe SimpleBenchmark, puis d’écrire des méthodes public int avec le préfixe times et un paramètre répétition utilisé dans une boucle for. Pour passer des paramètres particuliers au benchmark on utilisera un ou des champs annoté(s) par @Param.

Enfin comme Caliper lance une nouvelle VM, fait quelques travaux pour chauffer la VM (warmup), etc, il faut pour l’instant lancer ces tests avec une commande manuelle :

java -classpath $THE_CLASSPATH com.google.caliper.Runner PairCountsBenchmark

La ligne de commande pourra varier suivant les besoins ; on peut notamment se rendre sur leur site pour y voir les options (le lien wiki est à ce jour en retard par rapport au code) à passer au Runner Caliper. Malgré la jeunesse du framework sa documentation parfois spartiate, le projet a de réelles forces et s’avère de plus en plus populaire dans le domaine. Bien que le développement de ce projet avance lentement, ce projet est aujourd’hui maintenu par des membres de l’équipe Guava.

Donc le benchmark que j’ai mis en place :

public class PairCountsBenchmark extends SimpleBenchmark {

    @Param({ "1", "6", "25", "7", "111111111" }) private int K;  // différentes valeurs de la distance de la paire
    @Param({"10", "100", "1000", "10000"}) private int length;   // différentes tailles du tableau d'entier

    @Param private Distribution distribution;                    // Type de distribution SAWTOOTH, RANDOM, une autre

    private int[] values;

    @Override protected void setUp() throws Exception {          // Création du tableau d'entier
        values = distribution.create(length);
    }

    public int timePairCounts_V1(int repetition) {
        int dummy = 0;
        for (int i = 0; i < repetition; i++) {
            dummy += new PairCounts_V1().complementary_pairs(K, values);
        }
        return dummy;                                            // Variable modifiée dans la boucle pour forcer la JVM a ne pas supprimer cette boucle for.
    }

    public int timePairCounts_V2(int repetition) {
        int dummy = 0;
        for (int i = 0; i < repetition; i++) {
            dummy += new PairCounts_V2().complementary_pairs(K, values);
        }
        return dummy;
    }

    public enum Distribution {                                   // Le code de la distribution voulue
        SAWTOOTH {
            @Override
            int[] create(int length) {
                int[] result = new int[length];
                for (int i = 0; i < length; i += 5) {
                    result[i] = 0;
                    result[i + 1] = 1;
                    result[i + 2] = 2;
                    result[i + 3] = 3;
                    result[i + 4] = 4;
                }
                return result;
            }
        },
        RANDOM {
            @Override
            int[] create(int length) {
                Random random = new Random();
                int[] result = new int[length];
                for (int i = 0; i < length; i++) {
                    result[i] = random.nextInt();
                }
                return result;
            }
        };

        abstract int[] create(int length);
    }
}

Dans le temps

Voilà il faut maintenant lancer le benchmark en ligne de commande. Et voici une partie de la sortie standard :

0% Scenario{vm=java, trial=0, benchmark=PairCounts_V1, K=1, distribution=SAWTOOTH, length=10} 117.03 ns; σ=0.53 ns @ 3 trials
 1% Scenario{vm=java, trial=0, benchmark=PairCounts_V2, K=1, distribution=SAWTOOTH, length=10} 410.92 ns; σ=3.93 ns @ 5 trials
 3% Scenario{vm=java, trial=0, benchmark=PairCounts_V1, K=6, distribution=SAWTOOTH, length=10} 118.95 ns; σ=0.54 ns @ 3 trials
 4% Scenario{vm=java, trial=0, benchmark=PairCounts_V2, K=6, distribution=SAWTOOTH, length=10} 346.11 ns; σ=1.04 ns @ 3 trials
 5% Scenario{vm=java, trial=0, benchmark=PairCounts_V1, K=25, distribution=SAWTOOTH, length=10} 124.75 ns; σ=0.42 ns @ 3 trials
 6% Scenario{vm=java, trial=0, benchmark=PairCounts_V2, K=25, distribution=SAWTOOTH, length=10} 343.76 ns; σ=0.60 ns @ 3 trials
 8% Scenario{vm=java, trial=0, benchmark=PairCounts_V1, K=7, distribution=SAWTOOTH, length=10} 116.55 ns; σ=0.11 ns @ 3 trials
 9% Scenario{vm=java, trial=0, benchmark=PairCounts_V2, K=7, distribution=SAWTOOTH, length=10} 340.24 ns; σ=0.88 ns @ 3 trials
10% Scenario{vm=java, trial=0, benchmark=PairCounts_V1, K=111111111, distribution=SAWTOOTH, length=10} 124.34 ns; σ=1.17 ns @ 8 trials
11% Scenario{vm=java, trial=0, benchmark=PairCounts_V2, K=111111111, distribution=SAWTOOTH, length=10} 375.23 ns; σ=2.22 ns @ 3 trials
13% Scenario{vm=java, trial=0, benchmark=PairCounts_V1, K=1, distribution=RANDOM, length=10} 120.60 ns; σ=0.56 ns @ 3 trials
14% Scenario{vm=java, trial=0, benchmark=PairCounts_V2, K=1, distribution=RANDOM, length=10} 399.89 ns; σ=6.66 ns @ 10 trials
15% Scenario{vm=java, trial=0, benchmark=PairCounts_V1, K=6, distribution=RANDOM, length=10} 122.83 ns; σ=0.50 ns @ 3 trials
16% Scenario{vm=java, trial=0, benchmark=PairCounts_V2, K=6, distribution=RANDOM, length=10} 405.20 ns; σ=6.81 ns @ 10 trials
18% Scenario{vm=java, trial=0, benchmark=PairCounts_V1, K=25, distribution=RANDOM, length=10} 121.31 ns; σ=0.82 ns @ 3 trials
19% Scenario{vm=java, trial=0, benchmark=PairCounts_V2, K=25, distribution=RANDOM, length=10} 406.40 ns; σ=7.90 ns @ 10 trials
20% Scenario{vm=java, trial=0, benchmark=PairCounts_V1, K=7, distribution=RANDOM, length=10} 123.25 ns; σ=0.44 ns @ 3 trials
21% Scenario{vm=java, trial=0, benchmark=PairCounts_V2, K=7, distribution=RANDOM, length=10} 403.80 ns; σ=4.77 ns @ 10 trials
23% Scenario{vm=java, trial=0, benchmark=PairCounts_V1, K=111111111, distribution=RANDOM, length=10} 122.23 ns; σ=0.95 ns @ 3 trials
24% Scenario{vm=java, trial=0, benchmark=PairCounts_V2, K=111111111, distribution=RANDOM, length=10} 401.21 ns; σ=9.94 ns @ 10 trials
25% Scenario{vm=java, trial=0, benchmark=PairCounts_V1, K=1, distribution=SAWTOOTH, length=100} 3554.64 ns; σ=13.22 ns @ 3 trials
26% Scenario{vm=java, trial=0, benchmark=PairCounts_V2, K=1, distribution=SAWTOOTH, length=100} 3353.02 ns; σ=28.50 ns @ 4 trials
28% Scenario{vm=java, trial=0, benchmark=PairCounts_V1, K=6, distribution=SAWTOOTH, length=100} 3616.36 ns; σ=23.17 ns @ 3 trials
29% Scenario{vm=java, trial=0, benchmark=PairCounts_V2, K=6, distribution=SAWTOOTH, length=100} 2759.35 ns; σ=7.49 ns @ 3 trials
30% Scenario{vm=java, trial=0, benchmark=PairCounts_V1, K=25, distribution=SAWTOOTH, length=100} 3230.40 ns; σ=6.89 ns @ 3 trials
31% Scenario{vm=java, trial=0, benchmark=PairCounts_V2, K=25, distribution=SAWTOOTH, length=100} 2630.14 ns; σ=11.76 ns @ 3 trials
33% Scenario{vm=java, trial=0, benchmark=PairCounts_V1, K=7, distribution=SAWTOOTH, length=100} 3470.91 ns; σ=21.03 ns @ 3 trials
34% Scenario{vm=java, trial=0, benchmark=PairCounts_V2, K=7, distribution=SAWTOOTH, length=100} 2703.77 ns; σ=2.87 ns @ 3 trials
35% Scenario{vm=java, trial=0, benchmark=PairCounts_V1, K=111111111, distribution=SAWTOOTH, length=100} 3237.29 ns; σ=31.98 ns @ 3 trials
36% Scenario{vm=java, trial=0, benchmark=PairCounts_V2, K=111111111, distribution=SAWTOOTH, length=100} 3462.79 ns; σ=14.26 ns @ 3 trials
38% Scenario{vm=java, trial=0, benchmark=PairCounts_V1, K=1, distribution=RANDOM, length=100} 3664.38 ns; σ=22.84 ns @ 3 trials
39% Scenario{vm=java, trial=0, benchmark=PairCounts_V2, K=1, distribution=RANDOM, length=100} 4782.95 ns; σ=21.09 ns @ 3 trials
40% Scenario{vm=java, trial=0, benchmark=PairCounts_V1, K=6, distribution=RANDOM, length=100} 3666.78 ns; σ=11.56 ns @ 3 trials
41% Scenario{vm=java, trial=0, benchmark=PairCounts_V2, K=6, distribution=RANDOM, length=100} 4829.99 ns; σ=18.42 ns @ 3 trials
43% Scenario{vm=java, trial=0, benchmark=PairCounts_V1, K=25, distribution=RANDOM, length=100} 3669.01 ns; σ=3.86 ns @ 3 trials
44% Scenario{vm=java, trial=0, benchmark=PairCounts_V2, K=25, distribution=RANDOM, length=100} 4800.20 ns; σ=27.45 ns @ 3 trials
45% Scenario{vm=java, trial=0, benchmark=PairCounts_V1, K=7, distribution=RANDOM, length=100} 3697.72 ns; σ=16.69 ns @ 3 trials
46% Scenario{vm=java, trial=0, benchmark=PairCounts_V2, K=7, distribution=RANDOM, length=100} 4867.33 ns; σ=39.87 ns @ 3 trials
48% Scenario{vm=java, trial=0, benchmark=PairCounts_V1, K=111111111, distribution=RANDOM, length=100} 3663.00 ns; σ=18.92 ns @ 3 trials
49% Scenario{vm=java, trial=0, benchmark=PairCounts_V2, K=111111111, distribution=RANDOM, length=100} 4792.09 ns; σ=23.93 ns @ 3 trials
50% Scenario{vm=java, trial=0, benchmark=PairCounts_V1, K=1, distribution=SAWTOOTH, length=1000} 253205.17 ns; σ=2409.40 ns @ 3 trials
51% Scenario{vm=java, trial=0, benchmark=PairCounts_V2, K=1, distribution=SAWTOOTH, length=1000} 28733.38 ns; σ=57.50 ns @ 3 trials
53% Scenario{vm=java, trial=0, benchmark=PairCounts_V1, K=6, distribution=SAWTOOTH, length=1000} 252201.82 ns; σ=1916.34 ns @ 3 trials
54% Scenario{vm=java, trial=0, benchmark=PairCounts_V2, K=6, distribution=SAWTOOTH, length=1000} 26003.20 ns; σ=79.01 ns @ 3 trials
55% Scenario{vm=java, trial=0, benchmark=PairCounts_V1, K=25, distribution=SAWTOOTH, length=1000} 254835.90 ns; σ=1142.59 ns @ 3 trials
56% Scenario{vm=java, trial=0, benchmark=PairCounts_V2, K=25, distribution=SAWTOOTH, length=1000} 24830.33 ns; σ=96.51 ns @ 3 trials
57% Scenario{vm=java, trial=0, benchmark=PairCounts_V1, K=7, distribution=SAWTOOTH, length=1000} 336495.11 ns; σ=3182.70 ns @ 3 trials
59% Scenario{vm=java, trial=0, benchmark=PairCounts_V2, K=7, distribution=SAWTOOTH, length=1000} 25425.31 ns; σ=236.34 ns @ 4 trials
60% Scenario{vm=java, trial=0, benchmark=PairCounts_V1, K=111111111, distribution=SAWTOOTH, length=1000} 254613.30 ns; σ=591.19 ns @ 3 trials
61% Scenario{vm=java, trial=0, benchmark=PairCounts_V2, K=111111111, distribution=SAWTOOTH, length=1000} 31176.21 ns; σ=34.10 ns @ 3 trials
63% Scenario{vm=java, trial=0, benchmark=PairCounts_V1, K=1, distribution=RANDOM, length=1000} 264752.16 ns; σ=1911.17 ns @ 3 trials
64% Scenario{vm=java, trial=0, benchmark=PairCounts_V2, K=1, distribution=RANDOM, length=1000} 53425.63 ns; σ=530.29 ns @ 5 trials
65% Scenario{vm=java, trial=0, benchmark=PairCounts_V1, K=6, distribution=RANDOM, length=1000} 268841.98 ns; σ=1489.84 ns @ 3 trials
66% Scenario{vm=java, trial=0, benchmark=PairCounts_V2, K=6, distribution=RANDOM, length=1000} 58635.35 ns; σ=387.69 ns @ 3 trials
68% Scenario{vm=java, trial=0, benchmark=PairCounts_V1, K=25, distribution=RANDOM, length=1000} 266655.10 ns; σ=1012.10 ns @ 3 trials
69% Scenario{vm=java, trial=0, benchmark=PairCounts_V2, K=25, distribution=RANDOM, length=1000} 59015.10 ns; σ=814.55 ns @ 10 trials
70% Scenario{vm=java, trial=0, benchmark=PairCounts_V1, K=7, distribution=RANDOM, length=1000} 268504.45 ns; σ=482.22 ns @ 3 trials
71% Scenario{vm=java, trial=0, benchmark=PairCounts_V2, K=7, distribution=RANDOM, length=1000} 58601.33 ns; σ=568.63 ns @ 3 trials
73% Scenario{vm=java, trial=0, benchmark=PairCounts_V1, K=111111111, distribution=RANDOM, length=1000} 265022.05 ns; σ=1939.79 ns @ 3 trials
74% Scenario{vm=java, trial=0, benchmark=PairCounts_V2, K=111111111, distribution=RANDOM, length=1000} 58487.85 ns; σ=587.15 ns @ 10 trials
75% Scenario{vm=java, trial=0, benchmark=PairCounts_V1, K=1, distribution=SAWTOOTH, length=10000} 23462428.57 ns; σ=79476.07 ns @ 3 trials
76% Scenario{vm=java, trial=0, benchmark=PairCounts_V2, K=1, distribution=SAWTOOTH, length=10000} 285100.65 ns; σ=3403.03 ns @ 10 trials
78% Scenario{vm=java, trial=0, benchmark=PairCounts_V1, K=6, distribution=SAWTOOTH, length=10000} 42566217.39 ns; σ=189344.42 ns @ 3 trials
79% Scenario{vm=java, trial=0, benchmark=PairCounts_V2, K=6, distribution=SAWTOOTH, length=10000} 273497.95 ns; σ=2738.46 ns @ 7 trials
80% Scenario{vm=java, trial=0, benchmark=PairCounts_V1, K=25, distribution=SAWTOOTH, length=10000} 24271754.10 ns; σ=74440.46 ns @ 3 trials
81% Scenario{vm=java, trial=0, benchmark=PairCounts_V2, K=25, distribution=SAWTOOTH, length=10000} 257143.69 ns; σ=1045.68 ns @ 3 trials
83% Scenario{vm=java, trial=0, benchmark=PairCounts_V1, K=7, distribution=SAWTOOTH, length=10000} 33062666.67 ns; σ=154823.32 ns @ 3 trials
84% Scenario{vm=java, trial=0, benchmark=PairCounts_V2, K=7, distribution=SAWTOOTH, length=10000} 270617.53 ns; σ=1484.45 ns @ 3 trials
85% Scenario{vm=java, trial=0, benchmark=PairCounts_V1, K=111111111, distribution=SAWTOOTH, length=10000} 24082112.90 ns; σ=67162.43 ns @ 3 trials
86% Scenario{vm=java, trial=0, benchmark=PairCounts_V2, K=111111111, distribution=SAWTOOTH, length=10000} 296935.84 ns; σ=197.58 ns @ 3 trials
88% Scenario{vm=java, trial=0, benchmark=PairCounts_V1, K=1, distribution=RANDOM, length=10000} 24617137.50 ns; σ=222519.79 ns @ 4 trials
89% Scenario{vm=java, trial=0, benchmark=PairCounts_V2, K=1, distribution=RANDOM, length=10000} 837504.04 ns; σ=7730.54 ns @ 4 trials
90% Scenario{vm=java, trial=0, benchmark=PairCounts_V1, K=6, distribution=RANDOM, length=10000} 24380700.00 ns; σ=28021.86 ns @ 3 trials
91% Scenario{vm=java, trial=0, benchmark=PairCounts_V2, K=6, distribution=RANDOM, length=10000} 861687.14 ns; σ=7389.43 ns @ 3 trials
93% Scenario{vm=java, trial=0, benchmark=PairCounts_V1, K=25, distribution=RANDOM, length=10000} 24449950.00 ns; σ=137734.32 ns @ 3 trials
94% Scenario{vm=java, trial=0, benchmark=PairCounts_V2, K=25, distribution=RANDOM, length=10000} 865862.78 ns; σ=6500.68 ns @ 3 trials
95% Scenario{vm=java, trial=0, benchmark=PairCounts_V1, K=7, distribution=RANDOM, length=10000} 24474200.00 ns; σ=49916.49 ns @ 3 trials
96% Scenario{vm=java, trial=0, benchmark=PairCounts_V2, K=7, distribution=RANDOM, length=10000} 860750.64 ns; σ=8304.85 ns @ 6 trials
98% Scenario{vm=java, trial=0, benchmark=PairCounts_V1, K=111111111, distribution=RANDOM, length=10000} 24364925.00 ns; σ=72881.36 ns @ 3 trials
99% Scenario{vm=java, trial=0, benchmark=PairCounts_V2, K=111111111, distribution=RANDOM, length=10000} 840977.96 ns; σ=8104.18 ns @ 10 trials

    benchmark length distribution         K       ns linear runtime
PairCounts_V1     10     SAWTOOTH         1      117 =
PairCounts_V1     10     SAWTOOTH         6      119 =
PairCounts_V1     10     SAWTOOTH        25      125 =
PairCounts_V1     10     SAWTOOTH         7      117 =
PairCounts_V1     10     SAWTOOTH 111111111      124 =
PairCounts_V1     10       RANDOM         1      121 =
PairCounts_V1     10       RANDOM         6      123 =
PairCounts_V1     10       RANDOM        25      121 =
PairCounts_V1     10       RANDOM         7      123 =
PairCounts_V1     10       RANDOM 111111111      122 =
PairCounts_V1    100     SAWTOOTH         1     3555 =
PairCounts_V1    100     SAWTOOTH         6     3616 =
PairCounts_V1    100     SAWTOOTH        25     3230 =
PairCounts_V1    100     SAWTOOTH         7     3471 =
PairCounts_V1    100     SAWTOOTH 111111111     3237 =
PairCounts_V1    100       RANDOM         1     3664 =
PairCounts_V1    100       RANDOM         6     3667 =
PairCounts_V1    100       RANDOM        25     3669 =
PairCounts_V1    100       RANDOM         7     3698 =
PairCounts_V1    100       RANDOM 111111111     3663 =
PairCounts_V1   1000     SAWTOOTH         1   253205 =
PairCounts_V1   1000     SAWTOOTH         6   252202 =
PairCounts_V1   1000     SAWTOOTH        25   254836 =
PairCounts_V1   1000     SAWTOOTH         7   336495 =
PairCounts_V1   1000     SAWTOOTH 111111111   254613 =
PairCounts_V1   1000       RANDOM         1   264752 =
PairCounts_V1   1000       RANDOM         6   268842 =
PairCounts_V1   1000       RANDOM        25   266655 =
PairCounts_V1   1000       RANDOM         7   268504 =
PairCounts_V1   1000       RANDOM 111111111   265022 =
PairCounts_V1  10000     SAWTOOTH         1 23462429 ================
PairCounts_V1  10000     SAWTOOTH         6 42566217 ==============================
PairCounts_V1  10000     SAWTOOTH        25 24271754 =================
PairCounts_V1  10000     SAWTOOTH         7 33062667 =======================
PairCounts_V1  10000     SAWTOOTH 111111111 24082113 ================
PairCounts_V1  10000       RANDOM         1 24617138 =================
PairCounts_V1  10000       RANDOM         6 24380700 =================
PairCounts_V1  10000       RANDOM        25 24449950 =================
PairCounts_V1  10000       RANDOM         7 24474200 =================
PairCounts_V1  10000       RANDOM 111111111 24364925 =================
PairCounts_V2     10     SAWTOOTH         1      411 =
PairCounts_V2     10     SAWTOOTH         6      346 =
PairCounts_V2     10     SAWTOOTH        25      344 =
PairCounts_V2     10     SAWTOOTH         7      340 =
PairCounts_V2     10     SAWTOOTH 111111111      375 =
PairCounts_V2     10       RANDOM         1      400 =
PairCounts_V2     10       RANDOM         6      405 =
PairCounts_V2     10       RANDOM        25      406 =
PairCounts_V2     10       RANDOM         7      404 =
PairCounts_V2     10       RANDOM 111111111      401 =
PairCounts_V2    100     SAWTOOTH         1     3353 =
PairCounts_V2    100     SAWTOOTH         6     2759 =
PairCounts_V2    100     SAWTOOTH        25     2630 =
PairCounts_V2    100     SAWTOOTH         7     2704 =
PairCounts_V2    100     SAWTOOTH 111111111     3463 =
PairCounts_V2    100       RANDOM         1     4783 =
PairCounts_V2    100       RANDOM         6     4830 =
PairCounts_V2    100       RANDOM        25     4800 =
PairCounts_V2    100       RANDOM         7     4867 =
PairCounts_V2    100       RANDOM 111111111     4792 =
PairCounts_V2   1000     SAWTOOTH         1    28733 =
PairCounts_V2   1000     SAWTOOTH         6    26003 =
PairCounts_V2   1000     SAWTOOTH        25    24830 =
PairCounts_V2   1000     SAWTOOTH         7    25425 =
PairCounts_V2   1000     SAWTOOTH 111111111    31176 =
PairCounts_V2   1000       RANDOM         1    53426 =
PairCounts_V2   1000       RANDOM         6    58635 =
PairCounts_V2   1000       RANDOM        25    59015 =
PairCounts_V2   1000       RANDOM         7    58601 =
PairCounts_V2   1000       RANDOM 111111111    58488 =
PairCounts_V2  10000     SAWTOOTH         1   285101 =
PairCounts_V2  10000     SAWTOOTH         6   273498 =
PairCounts_V2  10000     SAWTOOTH        25   257144 =
PairCounts_V2  10000     SAWTOOTH         7   270618 =
PairCounts_V2  10000     SAWTOOTH 111111111   296936 =
PairCounts_V2  10000       RANDOM         1   837504 =
PairCounts_V2  10000       RANDOM         6   861687 =
PairCounts_V2  10000       RANDOM        25   865863 =
PairCounts_V2  10000       RANDOM         7   860751 =
PairCounts_V2  10000       RANDOM 111111111   840978 =

vm: java
trial: 0

Process finished with exit code 0

Donc en fait Caliper créé une matrice multi-dimensionnelle des différents paramètres et pour chaque coordonnée dans cette matrice lance le test, bref un Scénario.

On voit dans les mesures faites par Caliper le temps pris par chaque méthode, l’écart type, et le nombre d’essai. Enfin dans une deuxième partie Caliper donne un synopsis des différents run et en particulier une colonne très intéressante ‘linear time‘.

En observant le temps pris en fonction du nombre d’éléments pour chaque algo, on s’aperçoit que le temps pris par le premier algo augmente en effet par rapport au deuxième algo d’un facteur 5 qui augmente avec la taille du tableau. Bref on est loin d’un temps linéaire aka O(n).

Ce qui est aussi intéressant, c’est que le premier algo est plus efficace tant que le nombre d’élément dans le tableau d’entrée est inférieur à 100. Alors que la deuxième  qui utilise une structure plus élaboré ne montre des signes avantageux qu’à partir d’une centaine d’éléments. Ca me rappelle étrangement l’électronique ou les comportements des capacités et inductances changeant de nature lorsqu’on passe en haute fréquence.

Dans l’espace

Alors pour faire les mesures des allocations, on peut aussi utiliser caliper, mais à l’heure de l’écriture de ce blog, il faut faire quelques petites choses en plus.

1. Caliper 0.5 RC1 vient avec le jar java-allocation-instrumenter-2.0.jar qui est sensé servir d’agent, cependant ce jar n’a pas été généré correctement pour servir d’agent. En fait il faut télécharger le jar allocation.jar de ce projet : http://code.google.com/p/java-allocation-instrumenter/ daté du 1 er février 2012.
2. Avant de lancer le Runner en ligne de commande il faut ajouter la variable d’environnement ALLOCATION_JAR
   

   export ALLOCATION_JAR=/path/to/downloaded/allocation.jar

3. Enfin il est possible de lancer le même benchmark avec des tests sur la mémoire :
   

   java -classpath $THE_CLASSPATH --measureMemory com.google.caliper.Runner PairCountsBenchmark

A noter : Ne pas renommer allocation.jar en autre chose, sans ça vous n’aurez pas d’instrumentation !

Ce qui donne le résultat suivant, quasiment la même chose, mais avec les infos sur les allocations mémoire.

0% Scenario{vm=java, trial=0, benchmark=PairCounts_V1, K=1, distribution=SAWTOOTH, length=10} 119.06 ns; σ=1.08 ns @ 5 trials, allocated 1 instances for a total of 16B
 1% Scenario{vm=java, trial=0, benchmark=PairCounts_V2, K=1, distribution=SAWTOOTH, length=10} 468.80 ns; σ=4.56 ns @ 3 trials, allocated 9 instances for a total of 320B
 3% Scenario{vm=java, trial=0, benchmark=PairCounts_V1, K=6, distribution=SAWTOOTH, length=10} 115.83 ns; σ=0.46 ns @ 3 trials, allocated 1 instances for a total of 16B
 4% Scenario{vm=java, trial=0, benchmark=PairCounts_V2, K=6, distribution=SAWTOOTH, length=10} 426.45 ns; σ=3.65 ns @ 3 trials, allocated 9 instances for a total of 320B
 5% Scenario{vm=java, trial=0, benchmark=PairCounts_V1, K=25, distribution=SAWTOOTH, length=10} 125.06 ns; σ=0.52 ns @ 3 trials, allocated 1 instances for a total of 16B
 6% Scenario{vm=java, trial=0, benchmark=PairCounts_V2, K=25, distribution=SAWTOOTH, length=10} 407.38 ns; σ=1.42 ns @ 3 trials, allocated 9 instances for a total of 320B
 8% Scenario{vm=java, trial=0, benchmark=PairCounts_V1, K=7, distribution=SAWTOOTH, length=10} 116.38 ns; σ=1.11 ns @ 6 trials, allocated 1 instances for a total of 16B
 9% Scenario{vm=java, trial=0, benchmark=PairCounts_V2, K=7, distribution=SAWTOOTH, length=10} 425.28 ns; σ=0.46 ns @ 3 trials, allocated 9 instances for a total of 320B
10% Scenario{vm=java, trial=0, benchmark=PairCounts_V1, K=111111111, distribution=SAWTOOTH, length=10} 125.12 ns; σ=0.18 ns @ 3 trials, allocated 1 instances for a total of 16B
11% Scenario{vm=java, trial=0, benchmark=PairCounts_V2, K=111111111, distribution=SAWTOOTH, length=10} 439.33 ns; σ=3.29 ns @ 3 trials, allocated 19 instances for a total of 560B
13% Scenario{vm=java, trial=0, benchmark=PairCounts_V1, K=1, distribution=RANDOM, length=10} 121.67 ns; σ=0.46 ns @ 3 trials, allocated 1 instances for a total of 16B
14% Scenario{vm=java, trial=0, benchmark=PairCounts_V2, K=1, distribution=RANDOM, length=10} 482.23 ns; σ=3.74 ns @ 3 trials, allocated 34 instances for a total of 960B
15% Scenario{vm=java, trial=0, benchmark=PairCounts_V1, K=6, distribution=RANDOM, length=10} 120.69 ns; σ=0.71 ns @ 3 trials, allocated 1 instances for a total of 16B
16% Scenario{vm=java, trial=0, benchmark=PairCounts_V2, K=6, distribution=RANDOM, length=10} 455.67 ns; σ=3.55 ns @ 3 trials, allocated 34 instances for a total of 960B
18% Scenario{vm=java, trial=0, benchmark=PairCounts_V1, K=25, distribution=RANDOM, length=10} 121.64 ns; σ=0.42 ns @ 3 trials, allocated 1 instances for a total of 16B
19% Scenario{vm=java, trial=0, benchmark=PairCounts_V2, K=25, distribution=RANDOM, length=10} 464.34 ns; σ=7.45 ns @ 10 trials, allocated 34 instances for a total of 960B
20% Scenario{vm=java, trial=0, benchmark=PairCounts_V1, K=7, distribution=RANDOM, length=10} 120.85 ns; σ=0.38 ns @ 3 trials, allocated 1 instances for a total of 16B
21% Scenario{vm=java, trial=0, benchmark=PairCounts_V2, K=7, distribution=RANDOM, length=10} 454.11 ns; σ=5.22 ns @ 10 trials, allocated 34 instances for a total of 960B
23% Scenario{vm=java, trial=0, benchmark=PairCounts_V1, K=111111111, distribution=RANDOM, length=10} 122.14 ns; σ=1.12 ns @ 4 trials, allocated 1 instances for a total of 16B
24% Scenario{vm=java, trial=0, benchmark=PairCounts_V2, K=111111111, distribution=RANDOM, length=10} 481.91 ns; σ=7.18 ns @ 10 trials, allocated 34 instances for a total of 960B
25% Scenario{vm=java, trial=0, benchmark=PairCounts_V1, K=1, distribution=SAWTOOTH, length=100} 3530.68 ns; σ=18.40 ns @ 3 trials, allocated 1 instances for a total of 16B
26% Scenario{vm=java, trial=0, benchmark=PairCounts_V2, K=1, distribution=SAWTOOTH, length=100} 3095.60 ns; σ=7.39 ns @ 3 trials, allocated 9 instances for a total of 320B
28% Scenario{vm=java, trial=0, benchmark=PairCounts_V1, K=6, distribution=SAWTOOTH, length=100} 3677.07 ns; σ=36.07 ns @ 3 trials, allocated 1 instances for a total of 16B
29% Scenario{vm=java, trial=0, benchmark=PairCounts_V2, K=6, distribution=SAWTOOTH, length=100} 2871.70 ns; σ=96.87 ns @ 10 trials, allocated 9 instances for a total of 320B
30% Scenario{vm=java, trial=0, benchmark=PairCounts_V1, K=25, distribution=SAWTOOTH, length=100} 3253.18 ns; σ=16.46 ns @ 3 trials, allocated 1 instances for a total of 16B
31% Scenario{vm=java, trial=0, benchmark=PairCounts_V2, K=25, distribution=SAWTOOTH, length=100} 2830.61 ns; σ=61.72 ns @ 10 trials, allocated 9 instances for a total of 320B
33% Scenario{vm=java, trial=0, benchmark=PairCounts_V1, K=7, distribution=SAWTOOTH, length=100} 3868.67 ns; σ=36.13 ns @ 3 trials, allocated 1 instances for a total of 16B
34% Scenario{vm=java, trial=0, benchmark=PairCounts_V2, K=7, distribution=SAWTOOTH, length=100} 2747.84 ns; σ=26.29 ns @ 3 trials, allocated 9 instances for a total of 320B
35% Scenario{vm=java, trial=0, benchmark=PairCounts_V1, K=111111111, distribution=SAWTOOTH, length=100} 3240.13 ns; σ=12.72 ns @ 3 trials, allocated 1 instances for a total of 16B
36% Scenario{vm=java, trial=0, benchmark=PairCounts_V2, K=111111111, distribution=SAWTOOTH, length=100} 2941.78 ns; σ=39.47 ns @ 10 trials, allocated 109 instances for a total of 2720B
38% Scenario{vm=java, trial=0, benchmark=PairCounts_V1, K=1, distribution=RANDOM, length=100} 3703.12 ns; σ=9.85 ns @ 3 trials, allocated 1 instances for a total of 16B
39% Scenario{vm=java, trial=0, benchmark=PairCounts_V2, K=1, distribution=RANDOM, length=100} 4598.91 ns; σ=18.33 ns @ 3 trials, allocated 308 instances for a total of 10144B
40% Scenario{vm=java, trial=0, benchmark=PairCounts_V1, K=6, distribution=RANDOM, length=100} 3709.97 ns; σ=12.28 ns @ 3 trials, allocated 1 instances for a total of 16B
41% Scenario{vm=java, trial=0, benchmark=PairCounts_V2, K=6, distribution=RANDOM, length=100} 4520.00 ns; σ=27.93 ns @ 3 trials, allocated 308 instances for a total of 10144B
43% Scenario{vm=java, trial=0, benchmark=PairCounts_V1, K=25, distribution=RANDOM, length=100} 3665.28 ns; σ=13.51 ns @ 3 trials, allocated 1 instances for a total of 16B
44% Scenario{vm=java, trial=0, benchmark=PairCounts_V2, K=25, distribution=RANDOM, length=100} 4527.80 ns; σ=35.77 ns @ 3 trials, allocated 308 instances for a total of 10144B
45% Scenario{vm=java, trial=0, benchmark=PairCounts_V1, K=7, distribution=RANDOM, length=100} 3701.99 ns; σ=22.06 ns @ 3 trials, allocated 1 instances for a total of 16B
46% Scenario{vm=java, trial=0, benchmark=PairCounts_V2, K=7, distribution=RANDOM, length=100} 4498.57 ns; σ=45.15 ns @ 3 trials, allocated 308 instances for a total of 10144B
48% Scenario{vm=java, trial=0, benchmark=PairCounts_V1, K=111111111, distribution=RANDOM, length=100} 3729.27 ns; σ=16.84 ns @ 3 trials, allocated 1 instances for a total of 16B
49% Scenario{vm=java, trial=0, benchmark=PairCounts_V2, K=111111111, distribution=RANDOM, length=100} 4579.87 ns; σ=8.15 ns @ 3 trials, allocated 308 instances for a total of 10144B
50% Scenario{vm=java, trial=0, benchmark=PairCounts_V1, K=1, distribution=SAWTOOTH, length=1000} 254954.05 ns; σ=648.33 ns @ 3 trials, allocated 1 instances for a total of 16B
51% Scenario{vm=java, trial=0, benchmark=PairCounts_V2, K=1, distribution=SAWTOOTH, length=1000} 29495.00 ns; σ=202.71 ns @ 3 trials, allocated 374 instances for a total of 6160B
53% Scenario{vm=java, trial=0, benchmark=PairCounts_V1, K=6, distribution=SAWTOOTH, length=1000} 272123.84 ns; σ=1947.52 ns @ 3 trials, allocated 1 instances for a total of 16B
54% Scenario{vm=java, trial=0, benchmark=PairCounts_V2, K=6, distribution=SAWTOOTH, length=1000} 26549.46 ns; σ=169.74 ns @ 3 trials, allocated 374 instances for a total of 6160B
55% Scenario{vm=java, trial=0, benchmark=PairCounts_V1, K=25, distribution=SAWTOOTH, length=1000} 258246.52 ns; σ=1838.14 ns @ 3 trials, allocated 1 instances for a total of 16B
56% Scenario{vm=java, trial=0, benchmark=PairCounts_V2, K=25, distribution=SAWTOOTH, length=1000} 25816.29 ns; σ=238.66 ns @ 3 trials, allocated 374 instances for a total of 6160B
57% Scenario{vm=java, trial=0, benchmark=PairCounts_V1, K=7, distribution=SAWTOOTH, length=1000} 340760.25 ns; σ=714.81 ns @ 3 trials, allocated 1 instances for a total of 16B
59% Scenario{vm=java, trial=0, benchmark=PairCounts_V2, K=7, distribution=SAWTOOTH, length=1000} 26070.26 ns; σ=186.94 ns @ 3 trials, allocated 374 instances for a total of 6160B
60% Scenario{vm=java, trial=0, benchmark=PairCounts_V1, K=111111111, distribution=SAWTOOTH, length=1000} 255782.03 ns; σ=388.87 ns @ 3 trials, allocated 1 instances for a total of 16B
61% Scenario{vm=java, trial=0, benchmark=PairCounts_V2, K=111111111, distribution=SAWTOOTH, length=1000} 26950.40 ns; σ=491.82 ns @ 10 trials, allocated 1374 instances for a total of 30160B
63% Scenario{vm=java, trial=0, benchmark=PairCounts_V1, K=1, distribution=RANDOM, length=1000} 268871.49 ns; σ=2890.36 ns @ 10 trials, allocated 1 instances for a total of 16B
64% Scenario{vm=java, trial=0, benchmark=PairCounts_V2, K=1, distribution=RANDOM, length=1000} 50888.14 ns; σ=106.59 ns @ 3 trials, allocated 3011 instances for a total of 96528B
65% Scenario{vm=java, trial=0, benchmark=PairCounts_V1, K=6, distribution=RANDOM, length=1000} 268566.99 ns; σ=2398.41 ns @ 4 trials, allocated 1 instances for a total of 16B
66% Scenario{vm=java, trial=0, benchmark=PairCounts_V2, K=6, distribution=RANDOM, length=1000} 63228.83 ns; σ=495.26 ns @ 3 trials, allocated 3011 instances for a total of 96528B
68% Scenario{vm=java, trial=0, benchmark=PairCounts_V1, K=25, distribution=RANDOM, length=1000} 265538.89 ns; σ=323.95 ns @ 3 trials, allocated 1 instances for a total of 16B
69% Scenario{vm=java, trial=0, benchmark=PairCounts_V2, K=25, distribution=RANDOM, length=1000} 51922.10 ns; σ=491.28 ns @ 3 trials, allocated 3011 instances for a total of 96528B
70% Scenario{vm=java, trial=0, benchmark=PairCounts_V1, K=7, distribution=RANDOM, length=1000} 267048.78 ns; σ=1934.21 ns @ 3 trials, allocated 1 instances for a total of 16B
71% Scenario{vm=java, trial=0, benchmark=PairCounts_V2, K=7, distribution=RANDOM, length=1000} 54193.80 ns; σ=526.83 ns @ 3 trials, allocated 3011 instances for a total of 96528B
73% Scenario{vm=java, trial=0, benchmark=PairCounts_V1, K=111111111, distribution=RANDOM, length=1000} 270239.69 ns; σ=1291.59 ns @ 3 trials, allocated 1 instances for a total of 16B
74% Scenario{vm=java, trial=0, benchmark=PairCounts_V2, K=111111111, distribution=RANDOM, length=1000} 51265.07 ns; σ=547.18 ns @ 10 trials, allocated 3011 instances for a total of 96528B
75% Scenario{vm=java, trial=0, benchmark=PairCounts_V1, K=1, distribution=SAWTOOTH, length=10000} 23672536.59 ns; σ=131459.47 ns @ 3 trials, allocated 1 instances for a total of 16B
76% Scenario{vm=java, trial=0, benchmark=PairCounts_V2, K=1, distribution=SAWTOOTH, length=10000} 297356.00 ns; σ=1073.95 ns @ 3 trials, allocated 9374 instances for a total of 150160B
78% Scenario{vm=java, trial=0, benchmark=PairCounts_V1, K=6, distribution=SAWTOOTH, length=10000} 42248173.91 ns; σ=364119.70 ns @ 3 trials, allocated 1 instances for a total of 16B
79% Scenario{vm=java, trial=0, benchmark=PairCounts_V2, K=6, distribution=SAWTOOTH, length=10000} 273661.54 ns; σ=1544.97 ns @ 3 trials, allocated 9374 instances for a total of 150160B
80% Scenario{vm=java, trial=0, benchmark=PairCounts_V1, K=25, distribution=SAWTOOTH, length=10000} 24378375.00 ns; σ=184303.85 ns @ 3 trials, allocated 1 instances for a total of 16B
81% Scenario{vm=java, trial=0, benchmark=PairCounts_V2, K=25, distribution=SAWTOOTH, length=10000} 269039.83 ns; σ=123.09 ns @ 3 trials, allocated 9374 instances for a total of 150160B
83% Scenario{vm=java, trial=0, benchmark=PairCounts_V1, K=7, distribution=SAWTOOTH, length=10000} 33378571.43 ns; σ=154321.88 ns @ 3 trials, allocated 1 instances for a total of 16B
84% Scenario{vm=java, trial=0, benchmark=PairCounts_V2, K=7, distribution=SAWTOOTH, length=10000} 266848.28 ns; σ=1354.38 ns @ 3 trials, allocated 9374 instances for a total of 150160B
85% Scenario{vm=java, trial=0, benchmark=PairCounts_V1, K=111111111, distribution=SAWTOOTH, length=10000} 24348450.00 ns; σ=158682.88 ns @ 3 trials, allocated 1 instances for a total of 16B
86% Scenario{vm=java, trial=0, benchmark=PairCounts_V2, K=111111111, distribution=SAWTOOTH, length=10000} 281623.08 ns; σ=257.89 ns @ 3 trials, allocated 19374 instances for a total of 390160B
88% Scenario{vm=java, trial=0, benchmark=PairCounts_V1, K=1, distribution=RANDOM, length=10000} 24604800.00 ns; σ=84624.92 ns @ 3 trials, allocated 1 instances for a total of 16B
89% Scenario{vm=java, trial=0, benchmark=PairCounts_V2, K=1, distribution=RANDOM, length=10000} 826805.04 ns; σ=8011.71 ns @ 7 trials, allocated 30014 instances for a total of 931264B
90% Scenario{vm=java, trial=0, benchmark=PairCounts_V1, K=6, distribution=RANDOM, length=10000} 24467945.29 ns; σ=230301.47 ns @ 4 trials, allocated 1 instances for a total of 16B
91% Scenario{vm=java, trial=0, benchmark=PairCounts_V2, K=6, distribution=RANDOM, length=10000} 822419.69 ns; σ=8032.73 ns @ 9 trials, allocated 30014 instances for a total of 931264B
93% Scenario{vm=java, trial=0, benchmark=PairCounts_V1, K=25, distribution=RANDOM, length=10000} 24666650.00 ns; σ=65345.42 ns @ 3 trials, allocated 1 instances for a total of 16B
94% Scenario{vm=java, trial=0, benchmark=PairCounts_V2, K=25, distribution=RANDOM, length=10000} 819003.80 ns; σ=7662.68 ns @ 3 trials, allocated 30014 instances for a total of 931264B
95% Scenario{vm=java, trial=0, benchmark=PairCounts_V1, K=7, distribution=RANDOM, length=10000} 24432650.00 ns; σ=210910.19 ns @ 3 trials, allocated 1 instances for a total of 16B
96% Scenario{vm=java, trial=0, benchmark=PairCounts_V2, K=7, distribution=RANDOM, length=10000} 835849.98 ns; σ=9613.89 ns @ 10 trials, allocated 30014 instances for a total of 931264B
98% Scenario{vm=java, trial=0, benchmark=PairCounts_V1, K=111111111, distribution=RANDOM, length=10000} 24464100.00 ns; σ=41413.99 ns @ 3 trials, allocated 1 instances for a total of 16B
99% Scenario{vm=java, trial=0, benchmark=PairCounts_V2, K=111111111, distribution=RANDOM, length=10000} 835717.46 ns; σ=24729.21 ns @ 10 trials, allocated 30013 instances for a total of 931264B

 benchmark length distribution         K instances        B       ns linear runtime
PairCounts_V1     10     SAWTOOTH         1     1.000     16.0      119 =
PairCounts_V1     10     SAWTOOTH         6     1.000     16.0      116 =
PairCounts_V1     10     SAWTOOTH        25     1.000     16.0      125 =
PairCounts_V1     10     SAWTOOTH         7     1.000     16.0      116 =
PairCounts_V1     10     SAWTOOTH 111111111     1.000     16.0      125 =
PairCounts_V1     10       RANDOM         1     1.000     16.0      122 =
PairCounts_V1     10       RANDOM         6     1.000     16.0      121 =
PairCounts_V1     10       RANDOM        25     1.000     16.0      122 =
PairCounts_V1     10       RANDOM         7     1.000     16.0      121 =
PairCounts_V1     10       RANDOM 111111111     1.000     16.0      122 =
PairCounts_V1    100     SAWTOOTH         1     1.000     16.0     3531 =
PairCounts_V1    100     SAWTOOTH         6     1.000     16.0     3677 =
PairCounts_V1    100     SAWTOOTH        25     1.000     16.0     3253 =
PairCounts_V1    100     SAWTOOTH         7     1.000     16.0     3869 =
PairCounts_V1    100     SAWTOOTH 111111111     1.000     16.0     3240 =
PairCounts_V1    100       RANDOM         1     1.000     16.0     3703 =
PairCounts_V1    100       RANDOM         6     1.000     16.0     3710 =
PairCounts_V1    100       RANDOM        25     1.000     16.0     3665 =
PairCounts_V1    100       RANDOM         7     1.000     16.0     3702 =
PairCounts_V1    100       RANDOM 111111111     1.000     16.0     3729 =
PairCounts_V1   1000     SAWTOOTH         1     1.000     16.0   254954 =
PairCounts_V1   1000     SAWTOOTH         6     1.000     16.0   272124 =
PairCounts_V1   1000     SAWTOOTH        25     1.000     16.0   258247 =
PairCounts_V1   1000     SAWTOOTH         7     1.000     16.0   340760 =
PairCounts_V1   1000     SAWTOOTH 111111111     1.000     16.0   255782 =
PairCounts_V1   1000       RANDOM         1     1.000     16.0   268871 =
PairCounts_V1   1000       RANDOM         6     1.000     16.0   268567 =
PairCounts_V1   1000       RANDOM        25     1.000     16.0   265539 =
PairCounts_V1   1000       RANDOM         7     1.000     16.0   267049 =
PairCounts_V1   1000       RANDOM 111111111     1.000     16.0   270240 =
PairCounts_V1  10000     SAWTOOTH         1     1.000     16.0 23672537 ================
PairCounts_V1  10000     SAWTOOTH         6     1.000     16.0 42248174 ==============================
PairCounts_V1  10000     SAWTOOTH        25     1.000     16.0 24378375 =================
PairCounts_V1  10000     SAWTOOTH         7     1.000     16.0 33378571 =======================
PairCounts_V1  10000     SAWTOOTH 111111111     1.000     16.0 24348450 =================
PairCounts_V1  10000       RANDOM         1     1.000     16.0 24604800 =================
PairCounts_V1  10000       RANDOM         6     1.000     16.0 24467945 =================
PairCounts_V1  10000       RANDOM        25     1.000     16.0 24666650 =================
PairCounts_V1  10000       RANDOM         7     1.000     16.0 24432650 =================
PairCounts_V1  10000       RANDOM 111111111     1.000     16.0 24464100 =================
PairCounts_V2     10     SAWTOOTH         1     9.000    320.0      469 =
PairCounts_V2     10     SAWTOOTH         6     9.000    320.0      426 =
PairCounts_V2     10     SAWTOOTH        25     9.000    320.0      407 =
PairCounts_V2     10     SAWTOOTH         7     9.000    320.0      425 =
PairCounts_V2     10     SAWTOOTH 111111111    19.000    560.0      439 =
PairCounts_V2     10       RANDOM         1    34.000    960.0      482 =
PairCounts_V2     10       RANDOM         6    34.000    960.0      456 =
PairCounts_V2     10       RANDOM        25    34.000    960.0      464 =
PairCounts_V2     10       RANDOM         7    34.000    960.0      454 =
PairCounts_V2     10       RANDOM 111111111    34.000    960.0      482 =
PairCounts_V2    100     SAWTOOTH         1     9.000    320.0     3096 =
PairCounts_V2    100     SAWTOOTH         6     9.000    320.0     2872 =
PairCounts_V2    100     SAWTOOTH        25     9.000    320.0     2831 =
PairCounts_V2    100     SAWTOOTH         7     9.000    320.0     2748 =
PairCounts_V2    100     SAWTOOTH 111111111   109.000   2720.0     2942 =
PairCounts_V2    100       RANDOM         1   308.000  10144.0     4599 =
PairCounts_V2    100       RANDOM         6   308.000  10144.0     4520 =
PairCounts_V2    100       RANDOM        25   308.000  10144.0     4528 =
PairCounts_V2    100       RANDOM         7   308.000  10144.0     4499 =
PairCounts_V2    100       RANDOM 111111111   308.000  10144.0     4580 =
PairCounts_V2   1000     SAWTOOTH         1   374.000   6160.0    29495 =
PairCounts_V2   1000     SAWTOOTH         6   374.000   6160.0    26549 =
PairCounts_V2   1000     SAWTOOTH        25   374.000   6160.0    25816 =
PairCounts_V2   1000     SAWTOOTH         7   374.000   6160.0    26070 =
PairCounts_V2   1000     SAWTOOTH 111111111  1374.000  30160.0    26950 =
PairCounts_V2   1000       RANDOM         1  3011.000  96528.0    50888 =
PairCounts_V2   1000       RANDOM         6  3011.000  96528.0    63229 =
PairCounts_V2   1000       RANDOM        25  3011.000  96528.0    51922 =
PairCounts_V2   1000       RANDOM         7  3011.000  96528.0    54194 =
PairCounts_V2   1000       RANDOM 111111111  3011.000  96528.0    51265 =
PairCounts_V2  10000     SAWTOOTH         1  9374.000 150160.0   297356 =
PairCounts_V2  10000     SAWTOOTH         6  9374.000 150160.0   273662 =
PairCounts_V2  10000     SAWTOOTH        25  9374.000 150160.0   269040 =
PairCounts_V2  10000     SAWTOOTH         7  9374.000 150160.0   266848 =
PairCounts_V2  10000     SAWTOOTH 111111111 19374.000 390160.0   281623 =
PairCounts_V2  10000       RANDOM         1 30014.000 931264.0   826805 =
PairCounts_V2  10000       RANDOM         6 30014.000 931264.0   822420 =
PairCounts_V2  10000       RANDOM        25 30014.000 931264.0   819004 =
PairCounts_V2  10000       RANDOM         7 30014.000 931264.0   835850 =
PairCounts_V2  10000       RANDOM 111111111 30013.000 931264.0   835717 =

vm: java
trial: 0

Process finished with exit code 0

C’est effectivement une information utile, la première version de l’algo, ne fait en fait qu’une seule allocation de 16B (donc en fait un seul objet), c’est à dire peanuts, on est dans du O(1) en complexité spatiale. La deuxième qui est notamment basée sur une HashMap alloue nettement plus d’objets, mais est définitivement plus rapide, on a on ici une complexité spatiale de O(n).

Comme quoi il y a potentiellement des compromis à faire dans le choix d’un algo, la rapidité ou la faible consommation mémoire peuvent venir avec un coût dans une autre dimension.

Pour conclure

• Premier point, il faut absolument être au point pour des tests d’embauche plus sur le sujet, même si je trouve limité ces tests dans leur capacité à identifier ou filtrer les bons développeurs (l’algorithmie n’est pas certainement pas le seul critère d’un individu doué), c’est toujours bien de pouvoir les reéussir !
• Caliper offre un outillage plutôt facile d’utilisation pour faire des microbenchmark, dans la limite de validité d’un microbenchmark, il y a plein de mise en garde sur le sujet, sur le site de Caliper [1][2], Cliff Click en a parlé aussi à JavaOne [3][4].
• Quand on écrit du code c’est une bonne idée de penser à la complexité temporelle et spatiale, dont la notation pour les deux est le grand O. Caliper pourrait d’ailleurs se voir ajouter le moyen de mesurer la consommation mémoire (en lien avec la complexité spatiale). Évidement ce que je dis ne veut pas dire optimiser prématurément, mais juste de réfléchir à quel type de performance on peut s’attendre pour telle ou telle partie du code, et éventuellement de porter plus tard un effort spécifique.

A noter que Caliper offre d’autres possibilités de mesurer la performance à travers une méthode annotée par @ArbitraryMeasurement.

Original 22/08/2011 : Avec l’arrivée de Lion, Apple change les choses avec Java. Heureusement s’il s’agit d’une mise à jour depuis Snow Leopard, vous ne perdrez pas votre runtime JDK 6, en revanche si vous faites une installation clean, et bien il faudra télécharger le runtime ici :

http://support.apple.com/kb/DL1421

Bon ça fait une chose de plus pour nous ennuyer, mais bon comme toujours pour ceux qui veulent bosser sur un JDK 1.5, il vous faudra tricher un peu plus, il n’y a pas de mise à jour standard ou facile pour installer le JDK 5 sur 10.7.

Certains ont trouvé l’astuce en téléchargeant la mise à jour Java pour Mac OS X 10.5, et avec quelques outils et commandes dans le terminal. Cela dit le processus est un poil long. Du coup je me suis codé un petit script pour automatiser ces étapes. Pour l’instant le script repose sur un téléchargement manuel de cette mise à jour.

1. En premier on télécharge la mise à jour du JDK5 ici :
   

   http://support.apple.com/kb/DL1359

2. Ensuite dans le même répertoire on y téléchargera le script
3. Dans un terminal dans le dossier du téléchargement
   [plain]chmod +x install_jdk5_lion.sh[/plain]
4. Il faut être root, attention quand même, le script fonctionne sur les environnements Lion que j’ai pu testé, mais il peut très bien casser votre système, déclencher un tempête ou je ne sais quoi encore… je ne garantis rien.
   [plain]sudo -s[/plain]
5. Bref il se lance comme ça :
   [plain]./install_jdk5_lion.sh[/plain]
6. Si tout se passe bien alors, les préférences Java de Mac s’ouvriront en listant le JDK 5.
7. exit

En images, ça donne :

Evidement si vous repérez une coquille, je suis à l’écoute. Bonne soirée

EDIT 29/08/2011: Tant qu’à faire autant montrer comment avoir plusieurs JDK dans IntelliJ sous macosx.

1. Donc une fois le projet ouvert, il faut aller dans les préférences du projet (Project Settings).
   
2. Ensuite ajouter le JSDK.
   
3. Puis sélectionner dans l’explorateur le dossier /System/Library/Java/JavaVirtualMachines/1.5.0/Contents/Home
   
4. Hop, c’est fini, dans IntelliJ vous avez le JDK 5
   

Idée originale : Zend Studio 5.x for OS X Lion (Java SE 6)

Sources :

Mercredi 7 mars (à 19h) aura lieu la 2ème session Hackergarten. Après Soat, on a le plaisir d’être hébergé par Valtech (103 Rue de Grenelle, 75007 Paris) et il y aura des pizzas, gros merci à eux.

Hackergarten c’est le rendez-vous des gens qui veulent participer aux projets opensource. L’idée c’est, dans un format de 3h, de contribuer un logiciel, un fix, un feature, une documentation dont d’autres pourraient avoir l’usage. Il s’articule autour de commiters actifs pour mentorer les hackers qui participent à l’évènement.

Bref que du bon. Pour la planification de l’évènement c’est par là ⇒ http://hackergarten-paris.eventbrite.com/

Alors pour éviter les soucis de setup le jour J, ce post donne quelques informations sur ce qu’il y aurait à récupérer ou faire en avance sur votre machine. Si vous avez des questions ou si vous voulez participez aux discussions : inscrivez vous sur la mailing-list à cette adresse ⇒ http://groups.google.com/group/hackergarten-paris/

Hibernate OGM / Hibernate Search ⇐ mentoré par Emmanuel Bernard

IDE : IntelliJ mais Eclipse fait l’affaire

Pour builder : Maven 3.0.3
JDK 1.6 recommandé
changer les ~/.m2/settings.xml selon https://community.jboss.org/wiki/MavenGettingStarted-Users

Installer Cassandra 1.0.8 (download sur Apache)
Et pour les motivés NoSQL, installer votre moteur préféré aussi histoire de contribuer un dialect pour Hibernate OGM

Forker + cloner localement
– git clone https://github.com/hibernate/hibernate-search
– git clone https://github.com/hibernate/hibernate-ogm

Cloner
– git clone https://code.google.com/a/apache-extras.org/p/cassandra-jdbc/

Lancer mvn clean install sous chacun des clones pour être sûr que Maven télécharge bien la terre.

Maven / Jenkins ⇐ mentoré par Arnaud Héritier

IDE : Pour Maven & Jenkins : IntelliJ ou eclipse + m2e versions recentes si possibles

Git pour Jenkins, SVN pour Maven

Pour builder :  Maven 2.2.1 min, 3.0.x serait un mieux
(De memoire pas de settings additionnels pour seulement builder)

<mirror>
  <id>repo.jenkins-ci.org</id>
  <url>http://repo.jenkins-ci.org/public/</url>
  <mirrorOf>m.g.o-public</mirrorOf>
</mirror>

Infinitest ⇐ mentoré par David Gageot

Lancer mvn dependency:go-offline pour récupérer toutes les dépendances

Mockito ⇐ mentoré par Brice Dutheil

IDE : IntelliJ en particulier, la version Community suffira. Eclipse peut faire l’affaire. Attention on a eu des soucis avec Netbeans la dernière fois.

Pour Builder : Ant (IntelliJ contient un Ant)
JDK 5 préféré, mais pas obligatoire.

Forker et cloner localement depuis Google code : http://code.google.com/p/mockito/source/checkout
Attention ici c’est du mercurial.

Il n’y a plus qu’à ouvrir les fichiers du projet.

FluentLenium ⇐ mentoré par Mathilde Lemée

IDE : Un IDE qui gère maven, genre IntelliJ.

Pour Builder : Maven

Checkout depuis : https://github.com/FluentLenium/FluentLenium

Votre projet

Et oui si vous avez une idée à coder en Open Source et que vous cherchez des intéressés c’est peut-être l’endroit pour en parler et dresser un plan

1000 mercis

Gros merci à tous ceux qui participent aux Hackergarten Paris

• Arnaud Héritier
• Guillaume Laforge
• Emmanuel Bernard
• David Gageot
• Eric Lefevre
• Mathilde Lemée
• Et vous tous qui venez

Gros merci aussi à ceux qui hébergent l’évènement, c’est bien sympa :

• Soat
• Valtech

Évidement merci à Hamlet D’Harcy pour avoir initier l’idée là bas en Suisse

Après pas mal de travail avec des périodes plus ou moins intenses – bref les vicissitudes du développement Open Source – le projet sort une nouvelle version 1.9.0 en Release Candidate, avec des bugfixes et bien sûr des nouvelles features. Il y a un changelog mais dans les faits le billet suivant liste brièvement ce qui est nouveau. Ah oui la version est téléchargeable ici et bientôt disponible sur le central maven.

• Pour être plus fluent et expressif, l’API introduit les alias then et will pour les réponses personnalisées (Answer). Ainsi que d’autres petits tweak de l’API:
  

  @Test
  public void engine_should_only_work_with_diesel() {
    given(engine.start()).will(throwExceptionIfEssenceInsteadOfDiesel());
    // ...
  }
  
  private Answer throwExceptionIfEssenceInsteadOfDiesel() {
    return new Answer<EngineStatus>() {
      public EngineStatus answer(InvocationOnMock invocation) {
        // answer code
      }
    };
  }

• Les mocks peuvent maintenant être déclaré dans la configuration du stub, sur une ligne.
  

  DieselEngine de = given(mock(DieselEngine.class).start()).willThrow(TankIsEmpty.class).getMock();

• On peut maintenant renvoyer la classe d’une exception plutôt que son instance.
  

  given(someMock).willThrow(IllegalArgumentException.class, SomethingIsWrongException.class);

• Si jamais vous avez besoin de debugguer un bout de code ou les interactions sont non prédictibles, il est maintenant possible de loguer les invocations du mock ou de l’espion. Attention, bien qu’utile à l’occasion avec du code legacy, quand même si jamais ce besoin s’en fait sentir sur un nouveau développement c’est que ce code devient trop complexe.
  

  List mockedList = mock(List.class, withSettings().verboseLogging());
  mockedList.get(0);

  
  On pourra également ajouter des callbacks sur chaque interaction du mock.
  

  Observer observer = mock(Observer.class, withSettings().invocationListeners(listener1, listener2));
  willThrow(IllegalArgumentException.class).given(observer.update(observable, "what has changed"));

• Pas mal de travail a été fait sur les annotations. Maintenant il n’est plus nécéssaire d’initialiser un champ annoté par @Spy s’il existe dans la classe un constructeur sans argument.
  

  @RunWith(MockitoJUnitRunner.class)
  public class SomeTest {
    // pas besoin d'initialiser le champs
    @Spy private ArrayList spiedArrayList;
  
    @Test public void verify_some_interactions() {
      spiedArrayList.iterator();
      verify(spiedArrayList, once()).iterator();
    }
  }

• Et pour la fin mais pas des moindres, le mécanisme d’injection de mockito supporte maintenant l’injection par constructeur. A l’heure actuelle, seul les mocks et spies déclaré dans le test en tant que champs pourront être injecté dans le constructeur du champs annoté par @InjectMocks.
  

  @RunWith(MockitoJUnitRunner.class)
  public class EngineTest {
    @Mock Diesel diesel;
    @InjectMocks Engine engine;
  
    @Test public void engine_should_consume_Diesel() {
      engine.start();
    }
  }

  
  Ou Engine a un constructeur avec le paramètre Diesel.
  

  public class Engine {
    Diesel diesel;
    public Engine(Diesel diesel) {
      this.diesel = diesel;
    }
  
    public boolean start() {
      checkNotEmpty(diesel);
      // ...
    }
    // ...
  }

Pour l’instant en RC, cette release permettra d’adoucir les angles si nous en avons loupé certains éléments. N’hésitez pas à nous poser des questions sur la mailing list ou stackoverflow.

Pour ça je me suis créé dans mon IDE favori, IntelliJ, ce qu’on appelle des Live Template. Ces templates permettent à partir d’une abréviation d’insérer des fragments de code. Ainsi par exemple :

Taper iter dans votre éditeur puis de faire Ctrl+J (sous OSX) va développer cette abréviation dans le bout de code ci-dessous (suivant le contexte bien entendu)

for (TypeInIterable type : someIterable) {

}

Taper sur Ctrl+J (sous OSX) vous permet de lister les abréviations disponible dans le contexte courant.

Les Live Template pour Mockito

Bien qu’imparafaite pour des raisons de limite technique d’IntelliJ, elles sauvent un minimum de temps, multiplié par le nombre de test. Malheureusement il n’y a pas non plus d’import export uniquement pour les live template, il faut donc se taper la configuration de intellij à la main. Cela dit il est possible de contourner partiellement ce problème avec la sauvegarde de la configuration personnelle sur les serveurs intellij, ou encore d’exporter la configuration pour les live templates, les file templates, et encore autre chose.

J’ai défini toutes ces annotations dans un nouveau groupe ‘test’, et j’ai activé pour toutes le contexte Java, avec reformatage et simplification du nom qualifié.

1. Description : Creates a field with the @Mock annotation
   Abbréviation : ‘am’
   Template text :
   

   @org.mockito.Mock private $TYPE$ $MOCK_FIELD$

   Les variables du templates sont :

   Name	Expression	Default value	Skip if defined
   TYPE	variableOfType(“Object”)
   MOCK_FIELD	suggestVariableName()

2. Description : Creates a field with the @Spy annotation
   Abbréviation : ‘as’
   Template text :
   

   @org.mockito.Spy private $TYPE$ $MOCK_FIELD$

   Les variables du templates sont :

   Name	Expression	Default value	Skip if defined
   TYPE	variableOfType(“Object”)
   MOCK_FIELD	suggestVariableName()

3. Description : Creates a field with the @InjectMocks annotation
   Abbréviation : ‘aim’
   Template text :
   

   @org.mockito.InjectMocks private $TYPE$ $MOCK_FIELD$

   Les variables du templates sont :

   Name	Expression	Default value	Skip if defined
   TYPE	variableOfType(“Object”)
   MOCK_FIELD	suggestVariableName()

4. Description : Add @RunWith(MockitoJUnitRunner.class)
   Abbréviation : ‘rwm’
   Template text :
   

   @org.junit.runner.RunWith(org.mockito.runners.MockitoJUnitRunner.class)

5. Description : BDD Stub mock with given(…).willReturn(…) style
   Abbréviation : ‘gw’
   Template text :
   

   given($MOCK$).willReturn($ARGS$)$END$

   Les variables du templates sont :

   Name	Expression	Default value	Skip if defined
   MOCK	variableOfType(“Object”)
   ARGS

6. Description : BDD Stub spy/mock with willReturn(…).given(…) style
   Abbréviation : ‘wg’
   Template text :
   

   org.mockito.BDDMockito.willReturn($RETURNED$).given($MOCK$).$CALL$ $END$

   Les variables du templates sont :

   Name	Expression	Default value	Skip if defined
   RETURNED	complete()
   MOCK	variableOfType(“Object”)
   CALL	complete()

7. Description : Inserts a verify(…) statement
   Abbréviation :‘verif’
   Template text :

   org.mockito.Mockito.verify($MOCK$).$CALL$

   Les variables du templates sont :

   Name	Expression	Default value	Skip if defined
   MOCK	variableOfType(“Object”)
   CALL	complete()

8. Description : Inserts Mockito.inOrder(mocks) followed by inOrder.verify(…) statement
   Abbréviation : ‘ioverif’
   Template text :

   org.mockito.InOrder $inOrderVar$ = org.mockito.Mockito.inOrder($MOCKS$);
   $IN_ORDER_VAR$.verify($MOCK$).$CALL$;

   Les variables du templates sont :

   Name	Expression	Default value	Skip if defined
   IN_ORDER_VAR	suggestVariableName()
   MOCKS	variableOfType(“Object”)
   MOCK	variableOfType(“Object”)
   CALL	complete()

9. Description :Inserts a verify(…) statement
   Abbréviation :‘verif’
   Template text :

   $IN_ORDER_VAR$.verify($MOCK$).$CALL$;

   Les variables du templates sont :

   Name	Expression	Default value	Skip if defined
   IN_ORDER_VAR	variableOfType(“org.mockito.InOrder”)
   MOCK	variableOfType(“Object”)
   CALL	complete()

Voilà donc les templates que je me suis créé pour IntelliJ, il manque certainement des cas d’utilisation, mais je trouvais plus judicieux de mettre ces cas là au moins. Pour nos amis Eclipse oou Netbeans, il y a des fonctionnalités comparables plus ou moins évoluées (de mémoire le système d’Eclipse est plutôt pas mal).

Références

• Live Templates

Il faut ajouter dans la section build/plugins du pom une tache ant qui fera simplement un echo. A noter que cette tache est disponible dans la phase validate.

<build>
<plugins>

    <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-antrun-plugin</artifactId>
        <version>1.1</version>
        <executions>
            <execution>
                <phase>validate-property</phase>
                <goals>
                    <goal>run</goal>
                </goals>
                <configuration>
                    <tasks>
                        <echo>Displaying properties resolution</echo>
                        <echo>some.property]= ${some.property}</echo>
                        <echo>project.build.directory = ${project.build.directory</echo>

                        <echo>project.build.finalName= ${project.build.finalName}</echo>
                    </tasks>
                </configuration>
            </execution>
        </executions>
    </plugin>

</plugins>
<build>

Cela dit n’étant pas un expert maven, il y existe peut-être une solution plus élégante, un commentaire est le bienvenu dans ce cas.

Première approche; vous enregistrez vos MBean sur un MBeanServer, disons celui de la plateforme (avec Java 6 : ManagementFactory.getPlatformMBeanServer()).

mBeanServer.registerMBean(theMBean, theMBean.getObjectName());

Étant donné que MBeanServer étends MBeanServerConnection il est possible d’exécuter des querys, de faire des invocations sur les MBean etc. Si le code est suffisamment isolé des aspects techniques de connexion à JMX, vous passerez le MBeanServer en lieu et place de la MBeanServerConnection.

Supposons le code suivant.

public class OperateOnJMXConnection implements JMXOperation {

    public void perform(MBeanServerConnection connection) {
        // doing some stuff there
    }

    public Result getResult() { return result; }
}

Pour tester ce code il faudrait alors écrire :

@Test
public void do_not_fail() {
    operateOnJMXConnection.perform(mbeanServer);

    assertThat(result).satisfies(someCondition);
}

Mais voilà, vous restez en local, et par exemple si vous avez merdé sur la sérialisation de vos beans, vous ne verrez pas d’échec dans vos test et vous aurez une surprise en prod, ou avant si votre projet a un processus qualité décent.

Évidement il y a une solution, l’idée c’est de pouvoir se connecter au mBeanServer local à votre processus (typiquement dans maven 3, l’exécution de vos tests peuvent être forkée).

Alors j’ai essayé de récupérer les informations pour récupérer les informations de la VM qui tourne, mais bon on tombe dans des classes sun, j’ai préféré ne pas continuer sur ce chemin semé d’embûches, sans compter sur la faiblesse de cette approche.

Bref en relisant les articles de Khanh sur JMX, j’ai vu quelque chose d’intéressant JMXConnectorServerFactory. Cette classe permet donc de créer un JMXConnectorServer avec l’URL qu’on lui spécifie et d’un MBeanServer. A noter que cette URL doit respecter un certain formalisme tel que la javadoc l’indique : service:jmx:protocol:remainder.

Le protocole ne peut pas être n’importe quoi, il faut qu’il y ait le bon service enregistré pour qu’il soit géré. Dans notre cas RMI est standard, c’est donc le protocole que je prendrai. Pour le remainder, il s’agit plus d’une partie d’une URL, je vous laisse voir la Javadoc de JMXServiceUrl à ce sujet, mais dans les grandes lignes la forme doit être la suivante : //[host[:port]][url-path]

JMXConnectorServer connectorServer = JMXConnectorServerFactory.newJMXConnectorServer(
    new JMXServiceURL("service:jmx:rmi://"),
    null,
    mBeanServer
);

connectorServer.start();

Hop dans le code précédent, on a créé puis démarrer notre JMXConnectorServer. Il n’y a plus qu’à se connecter dessus de manière standard :
Je vais utiliser connectorServer.getJMXServer() pour récupérer l’URL du service, il y a une raison à cela, c’est que comme l’indique la javadoc, l’URL passée pour la création du JMXConnectorServer peut être légèrement modifiée par celui-ci, il faut donc récupérer la nouvelle URL.

JMXConnector jmxConnetor = JMXConnectorFactory.connect(connectorServer.getJMXServiceUrl());
MBeanServerConnection connection = jmx.getgetMBeanServerConnection();

Et voilà vous avez accès à une MBeanServerConnection, qui vit dans la JVM locale, mais qui utilise RMI pour communiquer avec le MBeanServer, du coup vous êtes nettement plus proches des conditions du code de production et c’est ce qui nous intéresse dans cet article.

Pour référence les articles de Khanh, et en français s’il vous plait :

• Partie 1 : http://jetoile.blogspot.com/2010/10/jmx-pour-les-nuls-les-concepts-partie-1.html
• Partie 2 : http://jetoile.blogspot.com/2010/11/jmx-pour-les-nuls-les-differents-mbeans.html
• Partie 3 : http://jetoile.blogspot.com/2010/11/jmx-pour-les-nuls-les-agents-jmx-partie.html
• Partie 4 : http://jetoile.blogspot.com/2010/11/jmx-pour-les-nuls-les-classes-de-base.html
• Partie 5 : http://jetoile.blogspot.com/2010/11/jmx-pour-les-nuls-le-mbean-server.html
• Partie 6 : http://jetoile.blogspot.com/2010/12/jmx-pour-les-nuls-chargement-dynamique.html
• Partie 7 : http://jetoile.blogspot.com/2010/12/jmx-pour-les-nuls-les-services-jmx.html
• Partie 8 : http://jetoile.blogspot.com/2010/12/jmx-pour-les-nuls-les-connecteurs.html

Quelques liens javadoc :

• JMXConnectorFactory
• JMXConnectorServerFactory
• JMXServiceURL
• JMXConnectorServer

Enfin je me suis créé une petite classe de commodité qui permet de créé facilement un loopback pour les TU :