Programme principal

Tous les programmes Java que vous avez écrits jusqu'ici n'étaient constitués que d'un seul fil d'exécution¹, généralement nommé le fil principal (main thread). Il est toutefois possible de créer plusieurs fils indépendants au sein d'un seul et même programme, comme nous allons l'illustrer.

Pour ce faire, nous utiliserons un programme d'exemple, dont la première version est tout à fait classique et ne comporte qu'un seul fil d'exécution :

public final class ThreadsExample {
  public static void main(String[] args) {
    print26('a');
    print26('A');
    System.out.print('_');
  }

  private static void print26(char c) {
    for (int i = 0; i < 26; i++)
      System.out.print((char)(c + i));
  }
}

Lorsqu'on exécute ce programme, il affiche bien entendu la ligne ci-dessous, le premier appel à print26 affichant l'alphabet en minuscule, le second affichant l'alphabet en majuscule, et le dernier appel à print affichant un caractère souligné (_) :

abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ_

On peut maintenant modifier ce programme pour faire en sorte que chacun des appels à print26 soit fait par un fil d'exécution séparé, représenté par une instance de Thread. La lambda passée au constructeur de cette classe contient le code que le fil exécutera dès qu'il aura été démarré, ce qui se fait en appelant sa méthode start.

public final class ThreadsExample {
  public static void main(String[] args) {
    new Thread(() -> print26('a')).start();
    new Thread(() -> print26('A')).start();
    System.out.print('_');
  }
  // … print26 identique à avant
}

Lorsqu'on exécute cette version modifiée du programme, trois fils d'exécution fonctionnent en parallèle : le fil principal, qui crée et démarre chacun des deux fils auxiliaires puis affiche un caractère souligné ; le premier fil auxiliaire, qui affiche l'alphabet en minuscule ; et le second fil auxiliaire qui affiche l'alphabet en majuscule.

Étant donné que ces trois fils s'exécutent en parallèle, il est possible que l'alphabet minuscule, l'alphabet majuscule et le caractère souligné soient entrelacés de manière arbitraire, plutôt que d'être affichés dans cet ordre comme initialement. On peut observer cela en exécutant plusieurs fois de suite le programme ci-dessus. Ainsi les dix lignes suivantes ont été obtenues en le lançant dix fois de suite :

abcdefghijklmnopqrstuvwxyzABCDEF_GHIJKLMNOPQRSTUVWXYZ
abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ_
abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ_
abcde_ABCDEFGHIJKLMNOPQRSTUVWXYZfghijklmnopqrstuvwxyz
abcdefghijklmnopqrstuvwxyz_ABCDEFGHIJKLMNOPQRSTUVWXYZ
abc_dABCDEFGHIJKLMNOPQRSTUVWXYZefghijklmnopqrstuvwxyz
abcdeABCDEFGHIJKLMNOPQRSTUVWXYZ_fghijklmnopqrstuvwxyz
abcdeABCDEFGHIJKLMNOPQRSTUVWXYZ_fghijklmnopqrstuvwxyz
abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ_
abcdeAB_CDEFGHIJKLMNOPQRfghijklmnopqrstuvwxyzSTUVWXYZ

Comme on le voit, différentes exécutions peuvent donner des résultats différents, car chaque fil procède de manière indépendante, à son propre rythme. Il est toutefois important de comprendre que chacun des fils s'exécute de manière séquentielle, comme d'habitude. Donc les lettres des alphabets minuscule et majuscule apparaissent toujours dans le bon ordre. Ce qui varie est l'entrelacement des différents alphabets et du caractère souligné.

Au démarrage d'une application JavaFX, un fil d'exécution nommé le fil (d'application) JavaFX (JavaFX [Application] Thread) est automatiquement créé par la méthode launch. C'est ce fil qui se charge ensuite d'appeler la méthode start.

Le fil JavaFX a pour but de gérer l'interface graphique, et c'est donc lui qui exécute, par exemple, tous les gestionnaires d'événement attachés au graphe de scène. Il faut de plus impérativement que ce soit lui qui exécute la totalité du code modifiant l'interface graphique. Il est très important de se souvenir de cela, car le non-respect de cette règle produit des plantages difficiles à diagnostiquer. De plus, il faut aussi être conscient du fait que tout blocage du fil JavaFX provoque un blocage de l'interface graphique. Il ne faut donc jamais bloquer ce fil pour une durée indéterminée.

Dans le cadre de Javions, nous utiliserons deux fils d'exécution. Le premier d'entre eux sera simplement le fil JavaFX, dont le but est de gérer l'interface graphique, comme nous l'avons dit. Le second fil sera quant à lui chargé d'obtenir les messages provenant des aéronefs, soit en démodulant le signal radio, soit en lisant les messages depuis un fichier.

Pour communiquer entre eux, ces deux fils utiliseront une file (queue) de message partagée. Le fil chargé d'obtenir les messages des aéronefs y placera les messages reçu, tandis que le fil JavaFX les en extraira périodiquement afin de mettre à jour l'interface graphique.

Il faut toutefois faire attention au type de file utilisé pour communiquer, car celles que nous avons vues jusqu'à présent — p. ex. ArrayDeque — ne peuvent pas être partagées entre plusieurs fils d'exécution. On dit qu'elles ne sont pas thread safe. En effet, si un fil d'exécution ajoute, par exemple, un élément à une file de type ArrayDeque alors qu'un autre fil d'exécution en retire simultanément un élément, il est possible que la file soit corrompue en conséquence. Là aussi, les problèmes que cela produit sont difficiles à diagnostiquer.

Dès lors, chaque fois que l'on désire ainsi partager des collections — ou n'importe quel autre valeur non immuable — entre plusieurs fils d'exécution, il faut impérativement s'assurer que ces objets partagés sont thread safe.

La bibliothèque Java offre plusieurs collections non immuables et thread safe — donc prévues pour être partagées par plusieurs fils d'exécution — dans le paquetage java.util.concurrent. Dans le cadre de ce projet, nous utiliserons uniquement ConcurrentLinkedQueue, qui implémente l'interface Queue et représente donc une file.

La §3.2.1.3 de l'étape 7 (Calcul de la trajectoire) suggère une technique de calcul de la trajectoire qui est inutilement compliquée. Il est possible de la simplifier ainsi :

• lorsqu'une nouvelle position est reçue, si l'altitude est connue, alors la paire (position courante, altitude courante) est ajoutée à la trajectoire,
• lorsqu'une nouvelle altitude est reçue, si la position est connue :
  • si la trajectoire est vide, alors la paire (position courante, altitude courante) est ajoutée à la trajectoire,
  • si l'horodatage du message courant est identique à celui du message qui a provoqué le dernier ajout à la trajectoire, alors son dernier élément est remplacé par la paire (position courante, altitude courante).

L'étape 7 spécifie que la méthode purge de la classe AircraftStateManager doit supprimer de l'ensemble des états observables ceux correspondants à des aéronefs dont aucun message n'a été reçu depuis une minute. Il n'est toutefois pas précisé si les accumulateurs correspondant à ces états doivent également être supprimés de la table.

Même si conserver les accumulateurs pourrait avoir certains avantages — en particulier si un aéronef est « perdu » durant plus d'une minute puis réapparaît —, cela présente également un inconvénient majeur : la table ne fait que grandir, potentiellement jusqu'au point où elle consomme la totalité de la mémoire à disposition et provoque le plantage du programme. Javions étant destiné à être exécuté sur une longue période, cela n'est pas souhaitable.

Dès lors, la méthode purge de AircraftStateManager doit supprimer aussi bien les accumulateurs que les états des aéronefs dont aucun message n'a été reçu dans la minute précédent la réception du dernier message passé à updateWithMessage.

La version originale de l'étape 10 spécifiait que la classe de style numeric devait être attachée aux cellules individuelles des colonnes numériques. Or il se trouve que l'attacher aux colonnes elles-mêmes fonctionne également, et comme cela est nettement plus simple, c'est ce qu'il faut faire.

Le graphe de scène de la ligne d'état est extrêmement simple et consiste en un panneau de type BorderPane auquel la feuille de style status.css est attachée et dont :

• la zone gauche (left) contient une instance de Text indiquant le nombre d'aéronefs visibles,
• la zone droite (right) contient une instance de Text indiquant le nombre de messages reçus depuis le début de l'exécution du programme,
• les trois autre zones (top, bottom et center) sont vides.

La propriété textProperty de l'instance de Text placée dans la zone gauche doit être liée de manière à ce que son contenu soit toujours égal à la chaîne ci-dessous :

Aéronefs visibles : ???

dans laquelle les trois points d'interrogation représentent le contenu de la propriété contenant le nombre d'aéronefs actuellement visibles.

De même, la propriété textProperty de l'instance de Text placée dans la zone droite doit être liée de manière à ce que son contenu soit toujours égal à la chaîne :

Messages reçus : ???

dans laquelle les trois points d'interrogation représentent le contenu de la propriété contenant le nombre de messages reçus depuis le début de l'exécution du programme.

Le graphe de scène de l'application consiste en un panneau de type SplitPane, d'orientation verticale, possédant deux fils qui sont, dans l'ordre :

• un panneau de type StackPane superposant la vue des aéronefs au fond de carte,
• un panneau de type BorderPane dont la zone centrale (center) est occupée par la table des aéronefs et la zone supérieure (top) par la ligne d'état.

Le titre de la fenêtre principale de l'application — la valeur de type Stage passée à start — est Javions, et ses dimensions minimales — réglables au moyen des méthodes setMinWidth et setMinHeight — sont de 800×600 unités.

La propriété de la ligne d'état contenant le nombre d'aéronefs visibles doit être liée à la taille de l'ensemble des aéronefs exporté par le gestionnaire d'états d'aéronefs (de type AircraftStateManager). Cela peut se faire facilement au moyen de la méthode size de Bindings.

La propriété de la ligne d'état contenant le nombre de messages reçus n'est quant à elle liée à rien, mais son contenu est modifié directement par le code chargé d'extraire les messages de la file.