Cours sur les aspects avancés de la programmation orientée objet en Java

Le CLASSPATH donne la liste des emplacements où la machine virtuelle est autorisée à charger des classes. S'il s'agit d'un nom de répertoire, il désigne la racine de l'arborescence correspondant aux packages. Si le CLASSPATH obtient des fichiers jar, les classes sont cherchées et chargées directement depuis l'intérieur de l'archive, la racine de l'arborescence correspondant à la racine de l'archive.

L'exemple suivant permet de charger le fichier ./unautreendroit/p/Decompilation.class, ou le fichier p/Decompilation.class à l'intérieur de archive.jar.

La création d'un jar se fait à l'aide de la commande jar :

> cd unautreendroit
unautreendroit> jar cvf archive.jar */*.class
manifest ajouté
ajout : p/Decompilation.class (39% compressés)

Comme pour la commande tar, on peut visualiser un jar :

jar tf archive.jar
META-INF/MANIFEST.MF
p/Decompilation.class

Les jar

La spécification des fichiers jar [JS] décrit l'utilisation du Manifest qui permet d'ajouter des informations pour l'utilisation du jar.

Ce Manifest contient :

• des informations générales (version, date et auteur, CLASSPATH des ressources requises) ;
• la classe contenant le main si ce jar contient une application qui est lancée via l'exécution de java -jar x.jar ;
• des informations pour les applets embarquées dans le jar ;
• des informations de signature.

Manifest-Version: 2.0
Created-By: 1.O (JFL)
Main-Class: p.Decompilation
Name: p/Decompilation.class
Digest_Algorithms: MD5
MD5-Digest: base64(ae322ab9de701f1e79bc2040b26349e9)

On peut alors construire et exécuter un jar comme suit :

jar cfm executable.jar Manifest.txt p/Decompilation.class
java -jar executable.jar
Out: 2

• Quelques variables sont importantes pour démarrer un programme Java. Ces variables sont aussi utiles pour des scripts shell permettant de lancer des applications Java.
• PATH : variable pour la recherche des exécutables.
• CLASSPATH : chargement dynamique des classes.
• JAVA_HOME : chargement dynamique des classes.

Sous Windows :

set JAVA_HOME=c:\jdk1.6
set JRE_HOME=c:\jdk1.6
set CLASSPATH=.;c:\tomcat\lib\servlet.jar

Sous Linux :

export JAVA_HOME=/usr/lib/jvm/java-6-sun
ls /usr/bin/java
/usr/bin/java -> /etc/alternatives/java
ls /etc/alternatives/java
/etc/alternatives/java -> /usr/lib/jvm/java-6-sun/jre/bin/java

Une frame est utilisée pour stocker des données locales, des résultats partiels, des valeurs de retour pour les méthodes et gère les exceptions. Une frame n'existe que le temps d'existence d'une méthode et est empilée sur la pile, ainsi que le thread ayant créé cette frame. Chaque frame possède :

• son propre tableau de variables locales ;
• sa propre pile d'opérandes ;
• une référence sur le runtime constant pool de la classe de la méthode courante.

Par conséquent, pour chaque thread, une seule frame est active à la fois à un moment donné. La frame courante cesse de l'être si une méthode est appelée ou si la méthode termine.

La pile d'opérandes est vide à la création de la frame. Les constantes et variables/attributs locaux sont poussés sur la pile. Les instructions à exécuter récupèrent les opérandes et poussent éventuellement des résultats sur la pile. La pile sert aussi à préparer des appels de fonctions. Par exemple, l'instruction iadd va opérer sur les deux entiers qui sont récupérés sur le haut de la pile. Une frame est utilisée pour restaurer l'état d'une fonction lors d'un retour d'un appel de fonction. Le retour de la fonction est poussé sur la pile de cette frame et le program counter reprend juste après le retour de fonction.

Dans le cas d'une exception, il n'y a pas de retour de fonction : la JVM va chercher dans la frame courante un handler ou sinon remonter à la frame appelante.

La manière la plus simple de déterminer les objets à collecter est de calculer l'atteignabilité d'un objet. Un objet est dit atteignable si et seulement s'il existe un chemin de références depuis les racines (les références du programme) jusqu'à cet objet.

Tous les objets sont situés dans le tas. Les variables locales sont, quant à elles, sur la pile. Chaque variable locale est soit un type primitif, soit une référence d'objet. Ainsi, les racines sont donc l'union de toutes les références des piles. Les racines contiennent aussi les objets constants comme les String dans le runtime constant pool. Par exemple, le runtime constant pool peut pointer sur des String de la pile contenant le nom de la classe ou des méthodes.

Deux grandes familles de ramasse-miettes peuvent être distinguées :

• ramasse-miettes par décompte de références (reference counting) ;
• ramasse-miettes par traces (tracing).

Le ramasse-miettes par décompte de référence collecte les objets lorsque le compteur tombe à zéro. Le problème d'un tel ramasse-miettes est l'overhead d'incrémentation/décrémentation, mais surtout la non-détection de cycles d'objets. Le ramasse miettes par traces parcourt le graphe des objets et pose une marque sur chacun d'eux. Puis les objets non marqués sont supprimés du tas. On appelle ce processus mark and sweep.

Quel que soit le type de ramasse-miettes, la présence de méthodes de finalisation impacte la phase sweep. Les objets non marqués sans méthode finalize peuvent être collectés à moins qu'ils ne soient référencés par des objets non marqués ayant une méthode finalize.

Pour combattre la fragmentation, deux stratégies similaires permettent de réduire la fragmentation de la pile après la désallocation d'objets :

• défragmentation par compactage (compacting) ;
• défragmentation par copie (copying).

La défragmentation par compactage déplace les objets marqués d'un côté de la pile, afin d'obtenir une large plage contigüe de l'autre : on compacte les objets d'un côté. En insérant un niveau d'indirection dans les adresses du tas d'objets, on évite le rafraichissement de toutes les références de la pile.

La défragmentation par copie déplace tous les objets dans une nouvelle zone de la pile. L'intégralité des objets étant déplacés, ils sont assurément contigus. Pour réaliser cette opération, une traversée totale des objets depuis les racines est obligatoire. Dans le cas d'un ramasse-miettes de ce type, on peut combiner la recherche d'objets à collecter et la défragmentation : l'ancienne zone mémoire est donc libre ou contenant des objets à désallouer. Ce processus élimine la phase de marquage et de collecte (mark and sweep). Une implémentation classique de ce procédé est appelée le ramasse-miettes stop and copy.

La pile est divisée en deux régions et les allocations se font dans l'une d'elles jusqu'à épuisement. Le programme est alors arrêté et les objets copiés dans l'autre partie à partir de la traversée du graphe d'objets. Le programme est relancé et les allocations se font dans la nouvelle région.

La durée de vie des objets impacte l'efficacité du ramasse-miettes. De nombreux objets (plus de 98 % dans des mesures expérimentales [GCH]) ont une durée de vie très courte : most objects die young. Le ramasse-miettes par copie est dans ce cas très efficace, car les objets meurent, car ils ne sont pas visités lors de la copie. Si l'objet survit après le premier passage du ramasse-miettes, il y a de grandes chances qu'il devienne permanent. Le ramasse-miettes par copie est peu performant sur ce type d'objets.

Inversement, le ramasse-miettes par marquage-compactage est performant sur les objets à durée de vie longue puisqu'ils sont compactés d'un côté de la pile et ne sont ensuite plus recopiés. Les ramasse-miettes par marquage sont pour leur part plus longs à exécuter puisqu'ils doivent examiner de nombreux objets dans la pile.

Un ramasse-miettes générationnel se base sur le principe de ségrégation des générations : certains objets sont dits jeunes et d'autres sont promus à un niveau de génération supérieur. Pour simplifier, on peut considérer deux générations : young generation et old generation.

Lorsqu'une allocation échoue, un trigger minor collection est déclenché, qui engendre la collection de la génération la plus jeune. Cette collection peut être très rapide et récupérer un espace mémoire important. Si la récupération est suffisante, le programme peut continuer, sinon une autre génération est attaquée.

La collection par générations successives peut engendrer la collection d'un objet jeune alors qu'un objet vieux pointe encore sur cet objet. En effet, le tas est divisé en plusieurs générations et tous les types de ramasse-miettes par copie ou marquage doivent parcourir les objets depuis les racines. L'algorithme de parcours se limite donc à une génération du tas, évitant de parcourir l'intégralité du tas. Il peut alors considérer un objet comme à collecter, car non marqué, alors qu'un objet de la vieille génération pointe encore dessus.

Le ramasse-miette doit donc construire la liste des références intergénérationnelles, par exemple lors de la promotion d'un objet jeune dans la vieille génération (méthode la plus efficace). Lors de l'analyse de la minor collection, ces références intergénérationnelles sont alors considérées comme des références racines, résolvant le problème évoqué ci-avant.

En Java, ces processus légers sont appelés thread. En pratique, on peut utiliser la classe Thread et Runnable, par exemple :

public class MyThread extends Thread {
public void run() { ... }
public class MyRunnable implements Runnable
public void run() { ... }

MyThread t = new MyThread();
t.start();
Thread t = new Thread(new MyRunnable);
t.start();

Un thread est actif lorsqu'il est en cours d'exécution de la méthode run(). Avant cet état, il est existant (ce qui correspond au new…). Il peut être éventuellement bloqué ou interrompu (interrupt()). Lorsque le thread atteint l'accolade fermante du run(), il a atteint sa fin d'exécution et peut être collecté par le garbage collector, à condition que l'utilisateur redonne la référence correspondante.

En cours d'exécution, il peut volontairement laisser la main à d'autres processus en utilisant les méthodes

sleep() ou pause().

Il existe aussi la possibilité de créer des processus lourds, depuis la machine virtuelle. Cela revient à un fork() suivi d'un execXX en C. Les classes à utiliser sont les classes Runtime et Process, par exemple :

Runtime.getruntime().exec("cmd");

Dans ces systèmes, les threads s'exécutent jusqu'à ce qu'ils décident de relâcher explicitement le processeur (instruction yield) pour laisser un autre thread s'exécuter. En d'autres termes, l'ordonnancement des threads doit être réalisé par le programmeur.

Avantages : le principal avantage de ce modèle est la simplicité de la gestion des données partagées. En effet, puisque les threads rendent explicitement la main, le problème des données partagées pouvant se trouver dans un état incohérent ne se pose pas.

Inconvénients : Le principal désavantage de telles implémentations est l'énorme difficulté voire l'impossibilité de le faire fonctionner sur plusieurs processeurs. On notera que la gestion de l'ordonnancement n'apporte pas que des avantages et pose notamment le problème de choisir intelligemment les endroits où réaliser un yield. Enfin, de telles implémentations demandent impérativement l'utilisation d'entrées/sorties non bloquantes (pas toujours disponibles) pour éviter que l'ensemble du processus soit bloqué.

Le mode coopératif exige de rendre explicitement le fil d'exécution du scheduler. Le scheduler est donc passif : il attend qu'un processus rende la main pour ensuite choisir le prochain processus.

L'algorithme FCFS (First-Come-First-Served) (premier arrivé, premier servi) est le plus simple des algorithmes d'ordonnancement. Le premier processus qui entre dans la file est le premier à bénéficier du processeur. Ce système est par contre très peu rentable. Les processus longs sont favorisés par rapport aux processus courts. Le type de gestion est non préemptif, car rien n'est prévu par le système d'exploitation pour déloger le processus du CPU, ou favoriser un processus dans la file.

Sur la figure ci-dessous, le scheduler choisit tout d'abord par priorité décroissante le processus à exécuter. Puis, à priorité égale, il donne la main séquentiellement à chaque processus.

Dans ces systèmes, il existe un thread particulier ou bien une partie du système d'exploitation (que l'on nomme scheduler ou ordonnanceur) qui est chargé de décider quel thread doit s'exécuter. Son rôle est de répartir au mieux (en fonction des priorités par exemple) les ressources du système. De ce fait le programmeur n'a pas à s'occuper de l'ordonnancement.

Avantages : les avantages de ce modèle sont multiples. La charge de définir un ordonnancement étant assurée par une entité externe la rend dynamique. Ceci a pour conséquence de la rendre beaucoup plus souple. De plus, l'utilisation d'entrées/sorties bloquantes ne pose plus aucun problème.

Inconvénients : le principal désavantage de ce modèle est la difficulté que pose la gestion des données partagées. En effet, puisque l'ordonnancement est externalisé aucune supposition ne peut être faite sur l'ordre d'exécution des threads et sur les interruptions du scheduler qui peuvent survenir à tout moment.

Pour un scheduler préemptif, le scheduler peut prendre la main pendant l'exécution d'un thread et donner le fil d'exécution à un thread en cours d'exécution. Sur la figure ci-dessous on montre le changement du fil d'exécution en plein milieu des processus.

L'algorithme round-robin est spécialement adapté aux systèmes en temps partagé. On définit un quantum de temps (time quantum) d'utilisation de l'unité centrale. La file d'attente des processus éligibles est vue comme une queue circulaire (fifo circulaire). Tout nouveau processus est placé à la fin de la liste.

De deux choses l'une, soit le processus actif rend le fil d'exécution avant la fin de sa tranche de temps (pour cause d'entrée/sortie ou volontairement) soit il est préempté, et dans les deux cas placé en fin de liste. Un processus obtiendra le processeur au bout de (n -1)T secondes au plus n nombre de processus et T longueur du quantum de temps) : la famine est donc assurément évitée.

Remarquons que si le quantum de temps est trop grand, round-robin devient équivalent à FCFS. De l'autre côté si le quantum de temps est très court, nous avons théoriquement un processeur n fois moins rapide pour chaque processus (n nombre de processus). Malheureusement si le quantum de temps est court, le nombre de changements de contexte dus à la préemption grandit, d'où une diminution du taux utile, d'où un processeur virtuel très lent. Une règle empirique est d'utiliser un quantum de temps tel que 80 % des processus interrompent naturellement leur utilisation de l'unité centrale avant l'expiration du quantum de temps.

Le choix a été de ne pas faire de choix. En effet, contraint par l'objectif d'être multiplateforme le langage Java a décidé de ne pas faire de spécifications trop contraignantes sur l'implémentation et le fonctionnement des threads. Java ne définit que quelques règles sur la nature des threads et la façon de les ordonnancer.

Toutefois, la spécification Java des threads permet une implémentation préemptive, ce qui permet d'effectuer un mapping des threads sur les threads du système d'exploitation hôte. Dans ce cas, le scheduler peut être par exemple du type round-robin.

La conséquence de ceci est que si l'on désire être réellement portable au sens de la spécification Java, il faut que les programmes puissent fonctionner (c'est-à-dire avoir un fonctionnement identique) quelles que soient les spécificités de l'implémentation. Ceci demande donc de faire des appels à la méthode yield, dans le cas d'une implémentation coopérative, sans pour autant profiter des avantages de cette implémentation (une meilleure maîtrise des données partagées).

Toutefois, la majorité des machines virtuelles que l'on trouve aujourd'hui sur les ordinateurs de bureau utilisent des threads préemptifs, à la différence de ce qui existe dans les Cards et dans certains systèmes embarqués. On peut donc raisonnablement partir du principe que, pour la programmation d'applications destinées au desktop, on considère que l'implémentation est préemptive.

Il est possible de changer la priorité d'un thread afin qu'il ait une priorité particulière pour accéder au processeur. Le thread de plus forte priorité accède plus souvent au processeur. Par défaut, un thread a la priorité de son père. Pour changer la priorité d'un thread, on utilise la méthode suivante : setPriority (int prio).

Seule la possibilité d'interrompre un processus a été gardée dans Java 1.5. Les méthodes permettant de stopper ou de suspendre un thread sont dépréciées, pour éviter de laisser des objets en cours de modification dans un état « non cohérent ». La méthode interrupt() positionne un statut d'interruption et peut lever des exceptions si le thread était en pause ou en cours d'utilisation d'entrées/sorties.

Les instructions des différents threads peuvent être exécutées à tour de rôle, dans un ordre qui dépend du choix du scheduler. Le scheduler donne le fil d'exécution du processeur à un thread pendant un certain temps, puis reprend la main, pour réévaluer le prochain thread qui prendra de nouveau le fil d'exécution.

Dans le cas où plusieurs processeurs sont disponibles, le scheduler s'occupe de répartir n threads sur m processeurs. On parle d'atomicité d'une instruction lorsque le scheduler ne peut pas prendre la main au cours de l'exécution de cette instruction. En Java, l'atomicité n'est garantie que sur les affectations (sauf pour les double et long).

Sinon, le scheduler peut interrompre l'exécution d'une instruction et lui redonner la main a posteriori pour terminer son accomplissement. Les instructions atomiques classiques sont par exemple l'ouverture d'un bloc synchronisé, la prise d'un jeton d'un sémaphore, ou l'acquisition d'un lock. Une erreur classique en programmation est de croire que le if est atomique ce qui peut conduire à des bogues liés à la concurrence de threads :

boolean array_access = false;
if (!array_access)
{
   array_access = true;
   ... // do the job
}
array_access = false;

Un thread peut attendre qu'un autre thread se termine. On utilise la méthode join() pour attendre la terminaison d'un autre fil d'exécution concurrent avant de continuer son propre fil d'exécution.

MyThread m1 = new MyThread();
MyThread m2 = new MyThread();
m1.start();
m2.start();
m1.join();
m2.join();

En cas d'attente, le thread ne consomme pas (ou peu) de temps CPU. On peut soi-même demander explicitement l'endormissement d'un thread pendant un temps donné en utilisant Thread.sleep(int temps), ce qui endort le thread courant (donc soi-même puisque c'est notre « moi-même » qui exécute cet appel). On peut aussi rendre explicitement la main au scheduler avec yield(), ce qui peut-être particulièrement utile lorsqu'on programme par exemple des interfaces graphiques.

// Affichage graphique
...
// Fin affichage graphique
Thread.yield();

Pour éviter de devoir créer un thread à chaque fois qu'une nouvelle tâche doit être exécutée, par exemple dans le cas classique d'un serveur web. On utilise dans ce cas un pool de threads, qui n'est rien d'autre qu'une collection de threads qui se nourrit de tâches disponibles dans une queue.

L'interface Executor permet de spécifier les méthodes classiques d'une tâche et l'on peut ensuite décider de différentes politiques d'exécutions des tâches en agissant sur des objets implémentant Executor.

Les politiques proposées dans Java 1.5 sont les suivantes : Excecutors.newCachedThreadPool() : un pool de threads de taille non limité, réutilisant les threads déjà créés et en créant des nouveaux au besoin. Après 60 secondes d'inactivité, le thread est détruit.

Excecutors.newFixedThreadPool(int n)x : un pool de threads de taille n. Si un thread se termine prématurément, il est automatiquement remplacé.

Excecutors.newSingleThreadExecutor() : crée un seul thread ce qui garantit la séquentialité des tâches mises dans la queue de taille non bornée.

Si l'on utilise des pools de threads de taille bornée, on peut se demander quelle est la taille optimale de l'ensemble. La loi d'Amdahl donne une bonne idée du dimensionnement optimal pour une utilisation maximale d'un système multiprocesseur. Si WT est le temps moyen d'attente d'une tâche et ST son temps moyen d'exécution, avec N processeurs la loi d'Amdahl propose un ensemble de threads de taille N/(1+WT/ST). Ceci ne tient évidemment pas compte des aléas temporels dus par exemple aux entrées/sorties.

Lorsque l'on souhaite synchroniser plusieurs threads entre eux, c'est-à-dire faire en sorte que les threads s'attendent les uns les autres (par exemple après un calcul distribué), on peut utiliser la classe CyclicBarrier qui bloquent les threads à une barrière (l'instruction CyclicBarrier.await() et les débloquent quand tous les threads y sont rendus. Cette barrière est cyclique, car elle peut-être réutilisée pour une prochaine utilisation (elle est réinitialisée).

La classe CountdownLatch est très similaire à CyclicBarrier, mais elle est plus adaptée à la coordination d'un groupe de threads ayant à traiter un problème divisé en sous-problèmes. Chaque thread décrémente un compteur en appelant countDown() après avoir traité une des tâches, puis est bloquée à l'appel de CyclicBarrier.await(). Le déblocage des threads ne se fait que lorsque le compteur atteint 0.

Enfin, la classe Exchanger permet de réaliser des échanges de données entre deux threads coopératifs. Il s'agit d'une barrière cyclique de deux éléments avec la possibilité supplémentaire de s'échanger des données lorsqu'ils atteignent la barrière.

L'exemple ci-dessous montre comment réaliser la gestion d'un tableau dynamique à accès concurrents à l'aide de blocs (ou méthodes) synchronisés.

public class TableauDynamique {
  private Object[] tableau; // le conteneur
  private int nb; // la place utilisée
  public TableauDynamique (int taille) {
    tableau = new Object[taille];
    nb = 0; }
  public synchronized int size() {
    return nb; }
  public synchronized Object elementAt(int i) throws NoSuchElementException {
    if (i < 0 || i = nb)
      throw new NoSuchElementException();
    else
      return tableau[i];
  }
  public void append(Object x) {
  Object[] tmp = tableau;
  synchronized(this) { // allouer un tableau plus grand si nécessaire
    if (nb == tableau.length) {
      tableau = new Object[3*(nb + 1)/2];
    for (int i = 0; i < nb; ++i)
      tableau[i] = tmp[i];
    }
    tableau[nb] = x;
    nb++;
  }
}}

Une méthode synchronisée peut appeler une autre méthode synchronisée sur le même objet sans être suspendue. En effet, le thread courant possède le moniteur sur l'instance de la classe dont on exécute la méthode : il peut donc appeler une autre méhode du même objet, ce moniteur étant déjà acquis. Les méthodes statiques peuvent aussi être synchronisées, mais la synchronisation se fait sur l'objet de type Class. Si une méthode non statique veut synchroniser son accès avec une méthode statique, elle doit se synchroniser relativement au même objet. Elle doit donc contenir une construction de la forme :

synchronized(this.getClass()){…}.

Le choix de l'objet sur lequel le moniteur est posé est primordial. Choisir this comme objet pour l'appel à synchronized(this) sans réfléchir et vérifier que l'exclusion est bien effective est une grossière erreur. En général, l'objet à passer à l'appel à synchroniser est l'objet à protéger et qui sera commun à tous les threads. Il est aussi possible de créer un objet ad hoc spécialement conçu pour la synchronisation.

Dans un certain sens, on revient alors à l'utilisation des classes implémentant Lock. Typiquement, un objet de type Ressource peut être utilisé par un thread pour exclure un autre threads :

// Quelque part dans le thread principal
Ressource r = new Ressource();
// Dans chaque portion de code exécutée dans des threads:
synchronized(r) {
  // ici, j'exclus les threads souhaitant poser un moniteur sur r
  ... }

L'interface Lock fournit les primitives nécessaires pour manipuler différentes classes de locks. Dans Java 1.5, ces classes ont un comportement spécifique qu'il faut adapter au type de modèle traité. Nous donnons par la suite deux exemples de locks particuliers.

Lock l = ...;
l.lock();
try {
    // access the resource protected by this lock
} finally {
    l.unlock();
}

Ce lock est dit réentrant dans le sens ou un thread possédant déjà ce lock et le demandant à nouveau ne se bloque pas lui-même. Ce type de blocage ne peut pas survenir avec un moniteur puisqu'un moniteur déjà posé sur une ressource est considéré comme acquis si un autre appel survient essayant un moniteur sur cette même ressource.

Ce lock fournit une implémentation permettant d'avoir une politique d'accès à une ressource avec plusieurs lecteurs et un unique écrivain. Les accès en lecture sont alors très efficaces, car réellement concurrents.

Le système de lock peut provoquer des interblocages ou deadlocks. L'exemple suivant utilise des objets de type Cell, cell1 et cell2. Si le thread1 exécute swapValue sur cell1, il prend le moniteur sur cell1. De même le thread2 peut prendre le moniteur sur cell2 où cell2=other dans le code cell1. Dans ce cas, à l'instruction other.getValue(), cell1 attend d'avoir le moniteur sur cell2 et inversement…

class Cell {
  private long value_;
  synchronized long getValue() { return value_;}
  synchronized void setValue(long v) {value_ = v;}
  synchronized void swapValue(Cell other) {
    long t = getValue();
    long v = other.getValue();
    setValue(v);
    other.setValue(t);
  }
 }

Une solution classique dite « d'ordre » permet de résoudre ce problème. Elle utilise la notion de préséance des locks : il s'agit de toujours prendre le lock sur l'objet ayant le plus grand hashcode, avant de passer au suivant.

void swapValue(Cell other) {
 if (other == this) return; // alias check
 Cell fst = this; // order via hash codes
 Cell snd = other;
 if (fst.hashCode() > snd.hashCode()) {
   fst = other;
   snd = this;
 }
 synchronized(fst) {
   synchronized (snd) {
     long t = fst.value;
     fst.value = snd.value;
     snd.value = t;
   }
 }
}

Une autre approche qui peut souvent porter ces fruits pour éliminer les problèmes de famine ou d'endormissement est la stratégie « diviser pour régner ». Plutôt que d'avoir un unique moniteur, celui-ci est subdivisé en plusieurs sous-moniteurs contrôlant chacun l'accès à une ressource particulière.

Cela permet de minimiser le temps d'attente des threads et augmente l'efficacité d'exécution du programme. Malheureusement, la multiplication des moniteurs favorise l'apparition de deadlocks. Si un thread doit poser plusieurs moniteurs sur plusieurs ressources, la possibilité d'un deadlock apparait. Une stratégie de résolution consiste à ne pas attendre un moniteur s'il est déjà pris : si un moniteur est occupé, on relâche alors tous les moniteurs déjà pris et on diffère l'action à réaliser.

Enfin, la meilleure stratégie pour éviter tout problème de liveness est de supprimer au maximum les exclusions mutuelles, quand cela est possible. Avant de supprimer l'exclusion mutuelle d'une partie de code, il est très important de penser aux deux règles suivantes :

• ne jamais avoir d'idée préconçue sur la progression relative de deux threads. En particulier toujours vérifier si le code est valide dans le cas où l'autre thread n'a même pas démarré ou s'il est déjà terminé ;
• supposer que le scheduler peut libérer le processeur du thread courant à n'importe quel point du code.

Les sémaphores permettent d'étendre la notion de lock en introduisant la manipulation de jetons (ou de permissions). Un sémaphore permet d'acquérir et de relâcher un jeton. Si un thread ne peut acquérir de jeton, il reste bloqué sur l'acquisition jusqu'à ce qu'un autre thread relâche un jeton. D'autres primitives permettent notamment de connaitre le nombre de jetons disponibles, d'essayer d'acquérir un jeton si possible, mais de manière non bloquante.

Il n'y a aucune contrainte sur l'identité des objets et des threads qui acquièrent ou relâchent un jeton d'un sémaphore. C'est donc un système très flexible, mais générateur de bogues, puisqu'on peut très facilement oublier de relâcher un jeton et bloquer d'autres threads. Pour éviter ce genre de problème, on peut déjà essayer d'acquérir et de relâcher des jetons au sein d'une même classe pour éviter la dispersion du code de gestion du sémaphore dans de multiples objets.

Notons enfin qu'un sémaphore ayant un seul jeton (ou permis) est appelé un sémaphore binaire et peut servir de lock d'exclusion mutuelle. La différence entre un sémaphore binaire et un lock réside dans le fait qu'un sémaphore binaire peut être relâché par un thread différent, ce que ne permet pas toujours de faire un lock (Lock n'est qu'une interface). Ceci peut être utile dans certains cas pour éviter des deadlock.

Semaphore s = new Semaphore(3, true);
s.acquire() // prend un jeton
s.release() // relache un jeton

Dans l'exemple suivant, 100 jetons sont disponibles. La classe Pool fournit des objets à l'utilisateur, mais n'est pas censé en fournir « trop ». Il serait par exemple interdit de donner le 101^e objet contenu dans le pool d'objets. En programmation non concurrente, un simple test suffirait. En programmation concurrente, l'utilisation d'un sémaphore devient obligatoire !

class Pool {
   private static final MAX_AVAILABLE = 100;
   private final Semaphore available =
                 new Semaphore(MAX_AVAILABLE, true);
   public Object getItem() throws InterruptedException {
     available.acquire();
     return getNextAvailableItem();
 }
   public void putItem(Object x) {
     if (markAsUnused(x))
       available.release();
   }
}

L'exemple suivant montre comment temporiser l'incrémentation, lorsque celle-ci n'est pas possible. Si l'utilisateur appelle inc() et que le compteur est déjà au maximum MAX, l'objet appelle tout d'abord attendIncrementable() qui ne rend la main que si l'on peut incrémenter. Si cela n'est pas possible, la méthode appelle wait() pour mettre « en pause » le thread courant, libérer l'objet et attendre d'être notifié d'un changement : en l'occurrence, on attend une décrémentation.

public interface Compteur {
public static final long MIN = 0; // minimum
public static final long MAX = 5; // maximum
public long value(); // valeur entre MIN et MAX
public void inc(); // incremente si value() < MAX
public void dec(); // decremente si value() MIN
}
public class CompteurConcurrent implements Compteur {
 protected long count = MIN;
 public synchronized long value() {
 return count;
 }
 public synchronized void inc() {
 attendIncrementable();
 setCount(count + 1);
 }
 public synchronized void dec() {
 attendDecrementable();
 setCount(count - 1);
 }
 protected synchronized void setCount(long newValue) {
 count = newValue;
 notifyAll();
 }
 protected synchronized void attendIncrementable() {
 while (count >= MAX)
 try { wait(); } catch(InterruptedException ex) {};
 }
 protected synchronized void attendDecrementable() {
 while (count <= MIN)
 try { wait(); } catch(InterruptedException ex) {};
 }
}

Les Timers permettent de planifier des tâches régulières. Il s'agit de réveiller des objets implémentant TimerTask à intervalles réguliers. On utilise la classe Timer pour spécifier les intervalles de valeurs. Toutes les tâches planifiées s'exécutent alors dans le même processus léger. On peut annuler un timer avec la méthode cancel() de Timer ou annuler une tâche planifiée en utilisant cette fois celle de TimerTask.

import java.util.*;
public class DateTask extends TimerTask {
  String msg;
  public DateTask(String msg) { this.msg = msg; }
  public void run() {
    System.out.println(Thread.currentThread().getName() +
                          " " + msg + ": " + new Date());
  }
}
public class TimerExample {
  public static void main(String[] args) {
    Timer timer = new Timer();
    DateTask task0 = new DateTask("task0");
    DateTask task1 = new DateTask("task1");
    DateTask task2 = new DateTask("task2");
    Calendar cal = Calendar.getInstance();
    cal.set(Calendar.HOUR_OF_DAY,17);
    cal.set(Calendar.MINUTE,14);
 cal.set(Calendar.SECOND,0);
    Date givenDate = cal.getTime();
    //task0: dès maintenant, toutes les 5 secondes
    timer.schedule(task0, 0, 5000);
    //task1: départ dans 2 secondes, toutes les 3 secondes
    timer.schedule(task1, 2000, 3000);
    //task2: une seule fois à la date fixée
    timer.schedule(task2, givenDate);
    System.out.println(Thread.currentThread().getName()
                                         + " terminé!");
  }

Pour illustrer comment un code peut être rendu thread-safe, on considère la servlet suivante :

public class UnsafeGuestbookServlet extends HttpServlet {
    private Set visitorSet = new HashSet();
    protected void doGet(HttpServletRequest httpServletRequest,
                   HttpServletResponse httpServletResponse)
                   throws ServletException, IOException {
        String visitorName = httpServletRequest.getParameter("NAME");
        if (visitorName != null)
            visitorSet.add(visitorName);
    }
}

Cette servlet peut être modifiée en remplaçant l'attribut privé par :

private Set visitorSet = Collections.synchronizedSet(new HashSet());

Ces wrappers introduisent cependant des difficultés au niveau des performances d'utilisation des collections. Si l'accès est fréquent ou si l'espace mémoire utilisé est important, l'utilisation de copies temporaires fait augmenter le nombre de traitements et l'espace mémoire occupé.

L'explication précédente se base sur l'idée que le plus simple est d'imposer l'exclusion mutuelle sur l'accès à une collection ; il suffit pour cela d'ajouter un synchronized sur les méthodes de classes pour garantir un comportement thread-safe. Ceci étant, il faut considérer les deux problèmes suivants :

• de nombreuses opérations sont composées (exemple : création d'un itérateur, puis appel à next() pour le parcours) et requièrent donc des mécanismes de synchronisation plus complexes ;
• certaines opérations comme get() peuvent supporter la concurrence, si l'on autorise la lecture multiple.

Pour ces raisons, Java 1.5 introduit un certain nombre de wrappers qui sont thread safe mais faiblement consistants.

Le premier exemple que l'on peut prendre, commun à toutes les collections, est l'itérateur faiblement consistant (weakly consitent). Lors de l'appel à next(), si un nouvel élément a été ajouté entretemps, il sera ou ne sera pas retourné par next(). De même, si un élément est enlevé entre deux appels à next(), il ne sera pas retourné pour les prochains appels (mais il a pu avoir été déjà retourné). Ceci étant, dans tous les cas, l'appel à next() ne lèvera pas l'exception ConcurrentModificationException.

Les mêmes idées d'accès robustes sont implémentées dans les structures de données classiques, au niveau des primitives d'accès. La classe CopyOnWriteArrayList permet de créer un wrapper d'accès à une liste (ArrayList) ou à un vecteur (Vector). Ce système de wrapper évite de proposer de nouvelles classes, remplaçant ArrayList et Vector et met en place le comportement suivant : lorsqu'un accès d'écriture modifie la structure, une copie de la liste ou du vecteur est créée et les itérations de parcours en cours se font sur cette copie. Lorsque toutes les itérations en cours sont terminées, la copie est alors détruite.

De même, un système de wrapper permet de transformer une HashMap en ConcurrentHashMap. Les opérations multiples sont autorisées, en lecture et en écriture et les itérateurs retournés sont weakly consistent. Ce wrapper est diamétralement opposé à Collections.synchronizedMap qui est une implémentation où chaque méthode est synchronisée garantissant l'exclusion mutuelle. Pour les ensembles, un système de wrapper permet de transformer un HashSet en set à accès concurrent.

Pour les queues, la classe ConcurrentLinkedQueue implémente une version thread safe d'une queue FIFO. Java 1.5 introduit des queues bloquantes, ce qui permet par exemple de faire attendre un producteur, lorsqu'un consommateur est trop lent par rapport au producteur. Ces classes implémentent l'interface BlockingQueue.

Juste après le découpage caractère par caractère vient naturellement l'accès par ligne au contenu d'un fichier. À partir des objets de type FileReader qui fournit le flux de caractères, la classe BufferedReader agrège le flux en le découpant à chaque carriage-return ("r"), ou line-feed ("n"). La taille du buffer peut être précisée à la construction.

BufferedReader inputStream = null;
PrintWriter outputStream = null;
try { inputStream = new BufferedReader(new FileReader("xanadu.txt"));
      outputStream = new PrintWriter(new FileWriter("characteroutput.txt"));
      String l;
      while ((l = inputStream.readLine()) != null) {
          outputStream.println(l);
    }

Cette implémentation est plus efficace en termes de performance grâce à l'utilisation du buffer. Le nombre d'appels à l'API native de lecture est réduit puisque la lecture s'opère depuis une zone mémoire, le buffer, qui n'est raffraichi que lorsque ce buffer est vide. Lors de l'écriture, le buffer est flushé automatiquement et peut être forcé par un appel à flush().

Dans le cas bufferisé ou non, les classes de lecture héritent de Reader et implèmentent Readable. La contrainte minimum de l'interface est très faible : il faut implémenter int read(CharBuffer cb).

Les entrées/sorties formatées permettent de découper le flux en mots projetés directement dans le type adéquat. Dans un premier temps, le formatage peut-être basé sur la classe String avec comme séparateur l'espace. La classe Scanner fournit l'implémentation de ce principe en travaillant par exemple sur un flux bufferisé qui se parcourt alors comme un itérateur :

Scanner s = new Scanner(new BufferedReader(new FileReader("xanadu.txt")));
while (s.hasNext()) {
    System.out.println(s.next());
}

Si le type du contenu est connu, des primitives permettent de projeter directement le mot dans la classe voulue, sauf si le prochain mot ne peut être interprété dans le type voulu :

s.useLocale(Locale.FRANCE);
while (s.hasNext()) {
    if (s.hasNextDouble()) {
            sum += s.nextDouble();
        } else { s.next(); }}

D'autres méthodes de Scanner permettent de manipuler le flux formaté :

• String findInLine(String pattern) : trouve le pattern spécifié ;
• public Scanner skip(Pattern pattern) : positionne le scanner sur le pattern ;
• Scanner reset(), Scanner useDelimiter(Pattern pattern)…

Les trois entrées/sorties standards des systèmes POSIX sont accessibles depuis la machine virtuelle au travers de la classe System :

• System.in : entrée standard (implémente OutputStream) ;
• System.out : sortie standard (implémente OutputStream) ;
• System.err : sortie d'erreur standard (implémente InputStream).

On peut y accéder en utilisant les classes OutputStreamWriter et InputStreamReader.

Une autre solution intéressante pour interagir avec la console est l'utilisation de la classe Console. Elle fournit notamment une implémentation plus sûre pour la lecture de mot de passe.

Console c = System.console();
if (c == null) {
         System.err.println("No console.");
         System.exit(1); }
char [] p = c.readPassword("Enter your password: ");

L'affichage des caractères est désactivé dans la console. De plus, l'implémentation de la récupération du mot de passe comme un tableau permet de désallouer plus rapidement que s'il s'agissait d'une String. Si le programme n'est pas attaché à une console ou qu'il n'est pas en interactivité avec une console, l'objet renvoyé est un pointeur null.

Les types simples supportent une projection directe de leur représentation dans un fichier. Les classes à utiliser sont DataInputStream et DataOutputStream. La classe String est elle aussi concernée, car son implémentation est spéciale. L'exemple suivant montre comment écrire et relire des types simples :

static final double[] prices = { 19.99, 9.99, 15.99, 3.99, 4.99 };
static final int[] units = { 12, 8, 13, 29, 50 };
static final String[] descs = { "Java T-shirt", "Java Mug" };
DataOutputStream out = new DataOutputStream(
                 new BufferedOutputStream(new FileOutputStream(dataFile)));
for (int i = 0; i < prices.length; i ++) {
  out.writeDouble(prices[i]);
  out.writeInt(units[i]);
  out.writeUTF(descs[i]);
}
DataInputStream  in = new DataInputStream(
                 new BufferedInputStream(new FileInputStream(dataFile)));
double price; int unit; String desc; double total = 0.0;
try { while (true) {
          price = in.readDouble();
          unit = in.readInt();
          desc = in.readUTF();
          System.out.format("You ordered %d units of %s at $%.2f%n",
                  unit, desc, price);
          total += unit * price;
      }
} catch (EOFException e) { }

L'intérêt de la sérialisation est d'automatiser l'écriture des dépendances de classes. L'écriture d'une classe agrégeant plusieurs objets provoque l'écriture des objets agrégés. Dans l'exemple suivant, l'instance de Maison est écrite automatiquement dans le fichier lorsque l'instance de PersonneIO est sérialisée.

/** Classe qui va être sérialisée. */
package io;
import java.io.Serializable;
public class PersonneIO implements Serializable {
  private int num_compte_bancaire = 8878;
  public String nom = "none";
  public Maison m;
  public PersonneIO() {
    m = new Maison("Mehun");
  }
  protected void setNom(String n) {
    nom = n;
  }
  public void setAdresse(String a) {
    this.m.adresse = a;
  }
}

Lors du processus d'écriture, les objets sont sérialisés à l'aide de la classe ObjectOutputStream. Un identifiant unique de sérialisation est calculé à la compilation : chaque instance sérialisée possède cet identifiant. Cela empêche le chargement d'un objet sérialisé ne correspondant plus à une nouvelle version de la classe correspondante.

package io;
import java.io.FileNotFoundException; import java.io.FileOutputStream;
import java.io.IOException; import java.io.ObjectOutputStream;
import java.io.Serializable;
public class PersonneIOMainWrite implements Serializable {
  public static void main(String[] args) {
    PersonneIO p = new PersonneIO();
    p.setNom("JFL");
    PersonneIO p2 = new PersonneIO();
    p2.setAdresse("?");
    FileOutputStream fos;
    try {   fos = new FileOutputStream("file.out");
      ObjectOutputStream oos = new ObjectOutputStream(fos);
      oos.writeObject(p);
      oos.writeObject(p2);
      oos.close(); }
      catch (FileNotFoundException e) { e.printStackTrace(); }
      catch (IOException e) { e.printStackTrace();
      }}}

À la relecture des objets sérialisés, il est impératif de connaitre l'ordre de sérialisation (on peut toutefois s'en sortir en faisant de l'introspection). L'exception particulière qui peut être levée est ClassNotFoundException dans le cas ou la JVM ne trouve pas la définition de la classe à charger.

package io;
import java.io.FileInputStream; import java.io.FileNotFoundException;
import java.io.IOException; import java.io.ObjectInputStream;
import java.io.Serializable;
public class PersonneIOMainRead implements Serializable {
  public static void main(String[] args) {
try { FileInputStream is = new FileInputStream("file.out");
      ObjectInputStream in = new ObjectInputStream(is);
      PersonneIO p = (PersonneIO)in.readObject();
      PersonneIO p2 = (PersonneIO)in.readObject();
      System.out.println(p.nom + " habite " + p.m.adresse);
      System.out.println(p2.nom + " habite " + p2.m.adresse);
      in.close();
    } catch (FileNotFoundException e) {
      e.printStackTrace();
    } catch (IOException e) {
      e.printStackTrace();
    } catch (ClassNotFoundException e) {
      e.printStackTrace();
    }}}

À la relecture, les méthodes setX() sont appelées afin de rétablir les attributs de l'objet qui sont relus dans le XML.

/** Écriture d'un objet JFrame sous forme d'un bean.
 *  (Exemple de "Java en concentré", D. Flanagan) */
package io;
import java.beans.XMLDecoder;
import java.io.BufferedInputStream;
import java.io.FileInputStream;
import java.io.FileNotFoundException;
public class LireBean {
  public static void main(String[] args) {
    try {
      BufferedInputStream in = new BufferedInputStream(
                               new FileInputStream("bean.xml"));
      XMLDecoder decoder = new XMLDecoder(in);
      Object b = decoder.readObject();
      javax.swing.JFrame frame = (javax.swing.JFrame)b;
      decoder.close();
    } catch (FileNotFoundException e) { e.printStackTrace(); }
  }}

La classe Path permet de manipuler un fichier ou une arborescence sous la forme d'un objet. La classe Paths fournit une méthode statique pour construire des objets Path à partir d'une String :

Path p1 = Paths.get("/tmp/foo");
Path p2 = Paths.get(args[0]);
Path p3 = Paths.get("file:///Users/joe/FileTest.java");

C'est en fait un raccourci vers l'objet FileSystems :

Path p4 = FileSystems.getDefault().getPath("/home/jf/java.rst");

Le constructeur de Path même s'il existe, est assez inutile puisqu'il ne raccroche pas l'objet instancié au système de fichiers.

L'objet instancié contient ensuite une représentation d'un chemin, de sa racine jusqu'au fichier ou au répertoire final. Cette représentation permet alors d'appeler les méthodes suivantes qui retournent toutes des objets de type Path :

• la méthode Path getName(n) permet de récupérer le énième élément du chemin, e.g. "jf" pour p4 avec n=1 ;
• la méthode Path getParent() renvoie le répertoire parent du chemin, e.g. /home pour p4 ;
• la méthode Path getRoot() renvoie la racine du chemin.

Certaines méthodes peuvent dépendre du système d'exploitation et de l'encodage de certaines informations pour le système de fichier. Par exemple, la méthode isHidden() se base sur la présence d'un « . » au début du nom de fichier pour les systèmes GNU/Linux alors que Microsoft Windows stocke cette information dans un fichier.

Dans l'exemple suivant, JTIO montre les résultats obtenus sur Path « sally/bar » sous Solaris et Windows :

Un chemin peut contenir des parties comportant de « . » ou des « .. », notamment si on les construit dynamiquement par concaténation. On peut donc par exemple se retrouver avec un chemin instancié sous la forme « /home/jf/. », ce qui n'est pas très élégant. La méthode normalize() permet de simplifier la représentation du chemin, sans s'occuper de l'existence réelle du fichier dénommé.

Une autre méthode permet de récupérer un chemin absolu : toAbsolutePath(). Cette méthode est particulièrement utile lorsque la méthode getRoot() renvoie un pointeur null (le chemin est relatif). La méthode toRealPath(b) combine les effets précédents : il est simplifié, puis si le chemin est relatif, il est converti, et si b est true les liens symboliques sont résolus.

Deux chemins peuvent être concaténés à l'aide de la méthode resolve() :

Path p1 = Paths.get("/home/joe/foo");          // Solaris
System.out.format("%s%n", p1.resolve("bar"));  // Result is /home/joe/foo/bar

À l'inverse, un chemin relatif peut être construit entre deux chemins :

Path p1 = Paths.get("home");
Path p3 = Paths.get("home/sally/bar");
Path p1_to_p3 = p1.relativize(p3);  // Result is sally/bar
Path p3_to_p1 = p3.relativize(p1);  // Result is ../..

Un chemin se parcourt en utilisant l'interface Iterable. L'itérateur parcourt le chemin à partir de la racine. De plus, un chemin implémente l'interface Comparable ce qui permet de trier des ensembles de chemins.

Souvent, on ne compare par l'égalité, mais si un chemin est un sous-chemin d'un autre. Deux méthodes sont proposées : startsWith(beginning) et endsWith(ending).

Path path = ...;
for (Path name: path) {
  System.out.println(name);
}
Path path = ...;
Path otherPath = ...;
Path beginning = Paths.get("/home");
Path ending = Paths.get("foo");
if (path.equals(otherPath)) {
//equality logic here
} else if (path.startsWith(beginning)) {
//path begins with "/home"
} else if (path.endsWith(ending)) {
//path ends with "foo"
}

La primitive checkAccess(AccessMode… modes) permet de vérifier si un certain nombre de droits sont présents sur le fichier dénommé par l'objet de type Path :

Path file = ...;
try {
  file.checkAccess(READ, EXECUTE);
  ...
} catch (IOException x) {
//Logic for error condition...
return;
}

On peut aussi vérifier si deux Path dénomment le même fichier sur le système de fichiers (incluant la prise en compte des liens symboliques le cas échéant) :

Path p1 = ...;
Path p2 = ...;
try {
if (p1.isSameFile(p2)) {
//Logic when the paths locate the same file
}} catch (IOException x) {
//Logic for error condition...
}

Un fichier se déplace à l'aide de moveTo(Path target, CopyOption… options), la copie est réalisée par une méthode similaire : copyTo(Path target, CopyOption… options), la suppression avec delete() :

Path path = ...;
Path newPath = ...;
path.moveTo(newPath, REPLACE_EXISTING);
Path newPath2 = ...;
newPath.copyTo(newPath2, REPLACE_EXISTING, COPY_ATTRIBUTES);
newPath2.delete();

Une nouvelle primitive permet de créer un fichier : createFile(). Pour les entrées/sorties, on utilise les classes vues précédemment à partir de l'InputStream récupéré sur le Path :

Path file = ...;
try {
file.createFile();
in = file.newInputStream();
BufferedReader reader = new BufferedReader(
                         new InputStreamReader(in));
OutputStream out = new BufferedOutputStream(
                    file.newOutputStream(CREATE, APPEND));

Les attributs d'un fichier peuvent être lus à travers la classe Attributes du package java.nio.file.attribute. Un appel statique à la méthode readBasicFileAttributes ou les méthodes spécifiques readDosFileAttributes et readPosixFileAttributes. Voici un exemple issu de [TOR]

import java.nio.file.attribute.*;
public class WindowsAttributePrinter {
public static void main(String args) throws IOException {
  for (String name : args) {
    Path p = Path.get(name);
    DosFileAttributes attrs =
              Attributes.readDosFileAttributes(path, false);
    if (attrs.isArchive()) {
      System.out.println(name + " is backed up.");
    }
    if (attrs.isReadOnly()) {
      System.out.println(name + " is read-only.");
    }
    if (attrs.isHidden()) {
      System.out.println(name + " is hidden.");
    }
    if (attrs.isSystem()) {
      System.out.println(name + " is a system file.");
  }}

L'interface FileVisitor<T> permet de parcourir une arborescence de répertoire ainsi que tous les fichiers contenus dans cette arborescence. Pensé comme un parseur SAX, le programmeur doit surcharger les méthodes suivantes qui sont déclenchées au cours de la visite :

• preVisitDirectory(T) : appelé avant chaque visite d'un répertoire ;
• preVisitDirectoryFailed(T, IOException) : invoqué en cas de visite impossible ;
• postVisitDirectory(T,IOException): appelé après chaque visite d'un répertoire ;
• visitFile et visitFileFailed*: appelé après chaque visite de fichier.

import static java.nio.file.FileVisitResult.*;
public static class PrintFiles extends SimpleFileVisitor<Path> {
  //Print information about each type of file.
  public FileVisitResult visitFile(Path file, BasicFileAttributes attr) {
      if (attr.isSymbolicLink()) {
          System.out.format("Symbolic link: %s ", file);
      } else if (attr.isRegularFile()) {
          System.out.format("Regular file: %s ", file);
      }
      return CONTINUE;
  }
  public FileVisitResult preVisitDirectoryFailed(Path d, IOException e) {
      System.err.println(e);
      return CONTINUE;
  }}

Le lancement du parcours de l'arborescence s'effectue à l'appel de Files.walkFileTree. Deux signatures différentes sont disponibles :

walkFileTree(Path start, FileVisitor<? super Path> visitor)
walkFileTree(Path start, Set<FileVisitOption> options, int maxDepth,
             FileVisitor<? super Path> visitor)

Dans les deux cas, le chemin de départ est donné ainsi que l'objet dérivant de FileVisitor. Dans la deuxième signature des options parmi FOLLOW_LINKS et DETECT_CYCLES et la profondeur maximale peuvent être précisées. La valeur retournée est particulièrement importante : elle est choisie parmi CONTINUE, TERMINATE, SKIP_SUBTREE, SKIP_SIBLINGS (abandon du répertoire courant et de ses frères).

Path startingDir = ...;
PrintFiles pf = new PrintFiles();
Files.walkFileTree(startingDir, pf);
EnumSet<FileVisitOption> opts = EnumSet.of(FOLLOW_LINKS);
Finder finder = new Finder(pattern);
Files.walkFileTree(startingDir, opts, Integer.MAX_VALUE, finder);

Le comportement du FileVisitor n'est pas spécifié. Dans la machine virtuelle de Sun, le parcours est en profondeur. Il est donc particulièrement important d'effectuer la bonne action dans la bonne méthode, par exemple si l'on encode une suppression récursive de répertoires.

Surveiller un répertoire permet de réagir à la modification du système de fichier. Un service de surveillance WatchService doit être créé et associé à un Path :

Surveiller un répertoire permet de réagir à la modification du système de fichier. Un service de surveillance WatchService doit être créé et associé à un Path:

À partir de cette clef, les événements sont récupérés à l'aide de la méthode pollEvents(). Ils peuvent ensuite être filtrés par types ENTRY_CREATE, ENTRY_DELETE, ENTRY_MODIFY, OVERFLOW.

for (WatchEvent<?> event: key.pollEvents()) {
  WatchEvent.Kind<?> kind = event.kind();
  if (kind == ENTRY_CREATE) {
    WatchEvent<Path> ev = (WatchEvent<Path>)event;
    Path filename = ev.context();
  }
}

Les méthodes suivantes renseignent sur la définition de la classe[JDOC] :

isAnonymousClass() : retourne vrai si et seulement si la classe est une classe anonyme ;

isArray() : détermine si l'objet représente un tableau ;

isAssignableFrom(Class<?> cls) : détermine si la classe ou l'interface représentée par ces objets est une super classe ou super interface de la classe cls passée en paramètre ;

isEnum() : retourne vrai si la classe est une énumération ;

isInstance(Object obj) Détermine si l'objet spécifié en paramètre est compatible avec la classe interrogée pour un possible assignement.

isInterface() : détermine si l'objet de type Classe est une interface ;

isPrimitive() : détermine si l'objet de type Classe est un type primitif.

Interfaces et classe mère

La recherche d'interfaces et d'une classe mère s'opère au travers des méthodes :

Class<? super T>     getSuperclass()
Class<?>[]   getInterfaces()

La classe mère peut être une classe, une interface, un type primitif ou void. Si la classe sur laquelle la méthode est appelée est Object ou une interface, un type primitif ou void, alors null est renvoyé. Les interfaces implémentées peuvent être multiples et sont renvoyées dans l'ordre de leur déclaration par le mot-clef implements. Si aucune interface n'est implémentée, le tableau est de taille 0.

Attributs

Les attributs de classes peuvent être récupérés à l'aide de Field[] getFields(). Cet attribut peut être modifié, par exemple à l'aide de setInt, setFloat… ou tout simplement la méthode set(Object obj,Object value) qui modifie l'attribut représenté par l'objet de type Field sur l'objet obj avec l'objet value.

Classe c = vehicule.getField("moteur");
Moteur m = new Moteur();
c.set(vehicule, m);

L'ensemble des constructeurs est renvoyé par la méthode suivante :

public Constructor<?>[] getConstructors() throws SecurityException

L'objet de type Constructor ainsi récupéré peut être à son tour inspecté. Par exemple, ses paramètres d'appel peuvent être récupérés :

Class<?>[]   getParameterTypes()

Un constructeur peut aussi être invoqué, afin de construire une nouvelle instance de l'objet que décrit la classe Class. On utilise pour cela la méthode T newInstance(Object… initargs) qui demande à la classe Class une nouvelle instance de classe, avec, comme paramètres (à nombre variable) les paramètres passés à la méthode.

La difficulté de l'utilisation de newInstance réside dans la découverte des paramètres du constructeur. En effet, il n'y a pas toujours de constructeurs sans paramètres permettant d'appeler newInstance().

String str = new String("test");
Class c = str.getClass();
String str2 = c.newInstance();

Les méthodes peuvent être récupérées dans un tableau d'objets Method. Il est aussi possible de chercher une méthode particulière à partir de son nom et de la liste des classes de ses paramètres (le nom n'est en effet pas suffisant) :

Method[]     getDeclaredMethods()
Method       getDeclaredMethod(String name, Class<?>... parameterTypes)

Une méthode peut ensuite être inspectée par exemple pour connaitre son type de retour à l'aide de Class<?> getReturnType(), ses paramètres à l'aide de Class<?>[] getParameterTypes(), les exceptions qu'elle est susceptible de lever à l'aide de Class<?>[] getExceptionTypes().

Une méthode peut ensuite être invoquée sur l'objet passé en premier paramètre à l'aide des paramètres (à nombre variable) dans les paramètres suivants :

Object invoke(Object obj, Object... args)