LA VERSION DE MA JVM ET LES CLASSPATH

Commentaire de verdy_p le 13/10/2007 06:06:23

Note: HashTable<K,V> a été modifié dans Java6 pour implémenter AUSSI l'interface Map<K,V>. Cela ne change pas l'arbre d'héritage (simple) de HashTable. Mais cela permet justement d'écrire la boite noire nécessaire. Du coup, HashTable n'est pas obsolète, au contraire de Dictionnary qui n'a pas subit le même traitemet (on se demande pourquoi ce qui était acceptable pour HashTable ne l'a pas été pour Dictionnary... sans doûte de sérieux problèmes de compatibilité du code de la librairie qui doit être capable de différencier une instance de Dictionnary d'une instance de Map par l'opération "instanceOf", et des problèmes de compatibilité lors de la désérialisation de flux sérialisés par une version précédente de Java, puisque cela modifie l'ordre de reconstruction des instances par les différents constructeurs d'objets de chaque type). Si on peut critiquer quelquechose dans la façon où la classe System a été étendue, est l'oubli de typage fort pour System.getProperties() qui se contente de retourner une "Enumeration<?>" alors qu'évidemment cela aurait dû être "Enumeration<String>" (quitte à ce que cela rende certaines implémentations de la ClassPath pour la JVM incompatible). Cela suggère que toutes les valeurs de clés retournées par System.getProperties ne sont pas forcément de type String (au contraire de ce que "dit" la classe "Properties"): c'est le cas en fait lors de l'initialisation de la JVM (quand la classe System est initialisée), même si plus tard dans nos programmes il ne reste que des clés de type String qui sont les seules accessibles par l'API documentée.

En revanche la class Properties a été étendue d'une autre façon: elle supporte la nouvelle méthode stringPropertyNames() qui retourne une "Enumeration<String>" sans qu'il soit nécessaire d'utiliser un typecast d'erasure (de la capture de ?) en Object (implicitement valide) ou String (quidoit êtrevérifié à l'exécution)

Aussi on peut écrire en Java6 bien plus proprement (plus aucun typecast):

        java.util.Enumeration<String> cles =
            System.getProperties().stringPropertyNames(); // pas de typecast ici!
        while (cles.hasMoreElements()) {
                String cle = cles.nextElement(); // pas de typecast ici !
                System.out.println( cle + " = " + System.getProperty(cle) );
        }

Cela répond au problème de performance (pas de vérification à l'exécution) et de sécurité du typage fort (vérification complète à la compilation). Mais ce n'est pas encore très pratique. On aimerait bien pouvoir simplifier cette syntaxe sansavoir à utiliser de variables d'états intermédiaires (source d'erreurs ou d'effets de bord dans les programmes).

Un exemple de classe miroir cachant le typecast effectué sur l'erasure des types "T<?>" en types "T", ici pour T=Enumeration:

class IterableEnumeration<T> implements java.util.Iterator<T> {
    private final java.util.Enumeration<T> e;
    public IterableEnumeration(java.util.Enumeration<T> e) {
        this.e = e;
    }
    public boolean hasNext() {
        return this.e.hasMoreElements();
    }
    public T next() {
        return this.e.nextElement();
    }
    public void remove() {
        throw new UnsupportedOperationException("Iterator's on IterableEnumeration's are not removable");
    }
}

On peut alors étendre Properties de cette façon (fonctionne aussi en Java 1.5) :

    class IterableProperties extends java.util.Properties implements java.lang.Iterable{
        public IterableProperties(java.util.Properties p) {
            super(p);
        }
        public IterableEnumeration<String> iterator() {
            return new IterableEnumeration<String>((java.util.Enumeration<String>)this.propertyNames()); // warning sur l'erasure...
        }
    }
Noter que ci-dessus l'erasure a été isolée dans le typecast de la méthode iterator, pour lequel il est simple de vérifier que l'ensemble retourné par propertyNames() ne contient que des String et non n'importe quel type d'objet.

On peut encore faire mieux en Java6 (pour Java 1.5 la version précédente sera nécessaire) pour éviter ce warning, en employant la méthode stringPropertyNames pour lequel cette assomption est totalement évitée:

class IterableProperties extends java.util.Properties implements java.lang.Iterable {
    public IterableProperties(java.util.Properties p) {
        super(p);
    }
    public IterableEnumeration<String> iterator() {
        return new IterableEnumeration<String>((java.util.Enumeration<String>)this.stringPropertyNames());
    }
}

Et ensuite on peut écrire de façon totalement sûre (grace au typage fort):

    for (String cle : new IterableProperties(System.getProperties()).iterator())
        System.out.println(cle + " = " + System.getProperty(cle))

C'est exactement ce qu'on voulait: plus de variable intermédiaire, pas même pour l'itérateur, plus moyen d'échapper au contrôle de "scope", et un programme totalement vérifiable (car totalement dépourvu de variable d'état ayant des effets de bord possibles), performant (plus de contrôle de type à l'exécution, ceci étant totalement vérifié par le compilateur).