I. Introduction▲
Comme dans n'importe quel logiciel, il peut arriver que l'utilisateur soit amené à exécuter une tâche de longue durée pour par exemple un calcul, charger ou sauvegarder un fichier, effectuer une requête web ou sur une base de données ou encore faire une pause pendant une durée déterminée ou effectuer une boucle infinie pour surveiller l'état d'un port, d'un périphérique ou d'un fichier.
Or si on ne prend pas attention à la manière dont ces tâches longues sont traitées, il est très facile de bloquer le fonctionnement de l'UI, ce qui laissera à penser à l'utilisateur que le programme a planté puisque plus rien ne répond à ses saisies. Fort heureusement, l'API JavaFX fournit via son API de concurrence une interface et une paire de classes tout spécialement dédiées à la gestion des tâches de fond, ce qui facilite grandement la gestion de ce genre d'opérations.
II. Problématique▲
II-A. Exemple▲
Prenons un problème simple : nous disposons d'une UI contenant un simple bouton et nous allons lancer le calcul de 1 000 000 d'entiers lorsque nous cliquons sur ce bouton. Nous allons également changer le curseur de l'UI et le remplacer par un curseur d'attente et nous désactiverons les boutons permettant de lancer le calcul pendant que ce dernier tourne.
Ce qui nous donne une interface similaire à celle-ci :
Nous pouvons désormais lancer notre calcul soit en cliquant directement sur le bouton Lancer le calcul !, soit en allant dans le menu Action -> Calculer.
Lorsque nous démarrons le calcul, nous pouvons nous rendre compte de plusieurs choses :
- le curseur ne change jamais d'apparence ;
- le bouton n'est jamais désactivé ;
- l'interface est complètement bloquée : il n'est plus possible d'aller dans les menus par exemple ou même de fermer la fenêtre normalement.
C'est bien normal : nous réagissons immédiatement à l'action sur le bouton ou le menu et nous exécutons notre long calcul dans le même thread que celui qui gère l'affichage et les événements dans l'UI. Cette dernière ne peut donc plus rafraichir son affichage ni même réagir à nos saisies.
Et souvenez-vous qu'il s'agit ici d'un simple calcul numérique, le problème se pose également lors de la lecture ou l'écriture de fichiers, d'un accès à une base de données, sur le réseau ou sur Internet…
II-B. Raisonnement▲
Tout comme Swing et AWT s'exécutent dans l'EDT (Event Dispatch Thread), JavaFX utilise des threads qui lui sont propres tels que le JavaFX Application Thread, le thread de rendu Prism ou encore le thread media. Les événements reçus via les listeners ou le binding ou encore les appels aux callbacks sont tous exécutés dans le JavaFX Application Thread.
Tout comme dans Swing et AWT, lancer un traitement long dans le thread de gestion des événements de JavaFX peut mener à un blocage (freeze) de l'UI de l'application qui ne répond alors plus aux entrées de l'utilisateur. Ce dernier peut alors être amené à penser que l'application est boguée ou plantée. Il faut donc exécuter ce genre de traitement en tâche de fond (background task) sans bloquer les threads de l'UI.
Bien qu'il soit possible de lancer manuellement un ou plusieurs Thread pour effectuer le traitement, la gestion de la remontée d'informations vers l'UI (progression, message, remontée des erreurs) peut s'avérer assez compliquée à programmer. C'est ici qu'intervient l'API de concurrence de JavaFX !
II-C. Solution▲
Reprenons notre code et utilisons l'API de concurrence de JavaFX. Pour cela, nous allons juste modifier le code de la méthode doCalculate() ainsi que les imports pour lister les nouvelles classes nécessaires. Nous reviendrons ultérieurement sur les diverses classes et mécanismes introduits dans ce code :
Désormais, notre programme se comporte comme prévu :
- le curseur change d'apparence au début et à la fin du calcul ;
- le bouton, ainsi que l'entrée dans le menu, est désactivé au début du calcul et réactivé lorsque ce dernier se termine ;
- l'interface n'est plus bloquée : nous pouvons naviguer dans les menus et nous pouvons fermer la fenêtre normalement.
Nous pouvons également voir que nous n'avons pas eu à créer un nouveau thread manuellement ni d'avoir à nous synchroniser dessus. Cependant le calcul s'est bien déroulé dans un autre fil d'exécution différent du JavaFX Application Thread.
III. Interfaces et classes importantes▲
III-A. javafx.concurrent.Worker<V>▲
Cette interface est l'entité parente des classes concrètes qui permettent de lancer une tâche de longue durée en fond de l‘UI. Vous ne serez pas amené à la manipuler directement, cependant vous pouvez remarquer la présence de plusieurs méthodes retournant des propriétés telles que progress, message, title, etc. qui permettent de suivre de la tâche depuis l'UI.
Le type V passé en paramètre de Worker est tout simplement le type de la valeur qui sera retournée par la méthode call(). C'est-à-dire le type du résultat de la tâche, car cette méthode est celle qui sera appelée pour effectuer la tâche de longue durée. Généralement, pour des tâches ne retournant pas de valeur, V sera soit non déclaré (et donc implicitement de type Object) ou de type Void avec une valeur de retour à null dans les deux cas.
Note : java.lang.Void est un type spécial de la JVM dont la seule valeur possible est null.
Un Worker dispose également d'une propriété état, state, qui changera de valeur au cours de la vie de la tâche. Les valeurs possibles de cet état sont définies dans l'enum Worker.State :
- READY - la tâche est prête à être exécutée ; c'est l'état initial ;
- SCHEDULED - la tâche est prévue pour être exécutée ; il s'agit d'un état intermédiaire entre READY et RUNNING ;
- RUNNING - la tâche démarre son exécution ;
- FAILED - la tâche a échoué, généralement à cause d'une exception qui a été levée au cours du traitement ;
- CANCELLED - la tâche a été annulée, généralement par l'utilisateur depuis l'UI ;
- SUCCEEDED - la tâche s'est correctement exécutée et a retourné son résultat.
Cette interface est implémentée par trois classes abstraites :
- Service<V> : une classe qui est instanciée et manipulée par l'UI pour créer, gérer et superviser la tâche de longue durée ;
- ScheduledService<V> : une classe qui est instanciée et manipulée par l'UI pour créer, gérer et superviser la tâche de longue durée qui peut se répéter à intervalles réguliers. JDK8 ou ultérieur ;
- Task<V> : une classe qui est instanciée et manipulée par le service ou le service répétable pour exécuter la tâche de longue durée dans un thread séparé.
III-B. javafx.concurrent.Service<V>▲
La classe Service est destinée à être utilisée et manipulée dans l'UI. Son seul vrai but est de créer une tâche (Task) qui sera exécutée en arrière-plan dans un autre thread. Une instance de Service est destinée à être réutilisable, vous pouvez donc conserver une référence sur une instance de Service et l'exécuter plusieurs fois d'affilée.
Pour instancier un service, il suffit de créer une nouvelle classe anonyme qui étend Service<V> et de surcharger la méthode abstraite createTask() pour qu'elle crée une Task<V> du même type que le service :
2.
3.
4.
5.
6.
7.
Service<Image> imageLoadingService = new Service<Image>(){
@Override
protected Task<Image> createTask() {
// Instancier et retourner une Task<Image> ici.
}
};
On peut aussi étendre Service<V> dans une classe à part :
2.
3.
4.
5.
6.
7.
public class ImageLoadingService extends Service<Image> {
@Override
protected Task<Image> createTask() {
// Instancier et retourner une Task<Image> ici.
}
};
III-C. javafx.concurrent.Task<V>▲
C'est cette classe qui sera amenée à faire le calcul, la requête ou le traitement de longue durée et c'est dans la méthode call() de cette classe que la tâche est effectuée ; cette méthode sera appelée dans un thread séparé, différent du JavaFX Application Thread.
Contrairement à Service, une Task est destinée à n'être exécutée qu'une seule et unique fois. Une tâche n'est pas réutilisable !
Pour créer une tâche, il suffit de créer une nouvelle classe anonyme qui étend Task<V> et de surcharger la méthode call() pour qu'elle renvoie une instance du type approprié :
2.
3.
4.
5.
6.
7.
8.
9.
Task<Image> imageLoadingTask = new Task<Image>(){
@Override
protected Image call() throws Exception {
// Charger l'image ici.
Image image = ...
return image;
}
};
On peut aussi étendre Task<V> dans une classe à part :
2.
3.
4.
5.
6.
7.
8.
9.
public class ImageLoadingTask extends Task<Image> {
@Override
protected Image call() throws Exception {
// Charger l'image ici.
Image image = ...
return image;
}
}
En plus des calculs, accès IO, requête web ou BD ou autre, vous pouvez faire tout ce que vous faites habituellement dans un thread au cours de ce traitement : boucle infinie, appel à Thread.sleep(), etc. sans pour autant que cela ne bloque l'UI.
Attention cependant, toute exception qui n'est pas catchée dans ce traitement remontera au niveau supérieur et passera automatiquement la tâche en l'état FAILED en plus d'arrêter le calcul ou le traitement en cours.
III-D. Javafx.concurrent.ScheduledService<V>▲
La classe ScheduledService, introduite dans le JDK8 permet de créer des services qui se répètent à intervalles réguliers. Elle fonctionne comme la class Service mais dispose de propriétés supplémentaires pour gérer la répétition ainsi que les conditions de gestion des échecs.
Un ScheduledService, se relance automatiquement lorsque son exécution précédente s'est terminée correctement une fois le temps d'attente spécifié par le programmeur écoulé. Il peut également se relancer en cas d'erreur d'exécution suivant les conditions de gestion des échecs qui ont été spécifiées.
IV. Utiliser un service▲
Vous serez donc amené à utiliser la classe Service depuis le code de votre UI, en réaction à un clic sur un bouton, dans un menu, une sélection dans une table, une liste ou un menu déroulant, etc. La majorité de ces actions s'exécutera donc dans le JavaFX Application Thread. Voyons donc maintenant comment utiliser un service.
IV-A. Création et lancement▲
Reprenons notre code qui permet d'initialiser notre service et complétons-le avec le code qui initialise la tâche :
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
Service<Image> imageLoadingService = new Service<Image>(){
@Override
protected Task<Image> createTask() {
return new Task<Image>(){
@Override
protected Image call() throws Exception {
// Charger l'image ici.
Image image = ...
return image;
}
};
}
};
imageLoadingService.start();
Ou, pour une tâche qui ne retourne rien :
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
Service<Void> fileSaveService = new Service<Void>(){
@Override
protected Task<Void> createTask() {
return new Task<Void>(){
@Override
protected Void call() throws Exception {
// Sauvegarder le fichier ici.
[...]
return null;
}
};
}
};
fileSaveService.start();
L'appel à la méthode start() du service, provoquera le démarrage de la tâche de fond dans un nouveau thread.
IV-B. Annulation▲
Pour annuler un service en cours d'exécution, il suffit d'appeler la méthode cancel() du service depuis l'UI (par exemple, un bouton). Lorsque la méthode cancel() est appelée, l'état du service et de la tâche passe à CANCELLED.
Attention, cela n'aura pas pour effet d'arrêter la tâche immédiatement ! Comme nous le verrons ultérieurement, vous devrez prendre des précautions supplémentaires dans la tâche pour vous assurer qu'elle termine bien son exécution.
imageLoadingService.cancel();
IV-C. Relancer un service▲
Pour qu'un service puisse être relancé, il doit être dans l'état READY, faute de quoi tout appel à la méthode start() se soldera par la levée d'une exception de type IllegalStateException. Il convient donc d'appeler sa méthode reset() avant d'appeler la méthode start(). À l'exécution, une nouvelle instance de Task sera alors créée et exécutée par le service.
2.
imageLoadingService.reset();
imageLoadingService.start();
Il est également possible d'appeler la méthode restart() qui fera exactement la même chose que le couple reset() + start() :
imageLoadingService.restart();
IV-D. Avancement du service▲
Il est possible de binder les propriétés retournées par progressProperty(), messageProperty(), titleProperty(), etc. d'un service vers des éléments de l'UI tels que des instances de Label, ProgressBar ou ProgressIndicator de manière à suivre l'avancement de l'exécution et les changements d'état de la tâche de fond.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
Stage dialog = ...
ProgressIndicator progressIndicator = ...
Label informationLabel = ...
[...]
Service<Image> imageLoadingService = new Service<Image>() {
[...]
};
dialog.titleProperty().bind(imageLoadingTask.titleProperty());
progressIndicator.progressProperty.bind(imageLoadingTask.progressProperty()) ;
informationLabel.textProperty().bind(imageLoadingTask.messageProperty());
imageLoadingService.start();
Il est aussi possible de mettre des ChangeListener sur chacune de ces propriétés pour transmettre leurs changements de valeur sur d'autres éléments de l'UI.
IV-E. État du service▲
En général vous aurez envie de superviser les changements d'état d'un service de manière à afficher des messages d'erreur ou de succès d'opération dans votre UI.
Pour superviser les changements d'état d'une tâche de fond, vous avez deux possibilités.
IV-E-1. ChangeListener sur l'état du service▲
Vous pouvez mettre un écouteur de type ChangeListener sur la propriété state du service et superviser les changements de valeur de cette propriété :
IV-E-2. Callback sur le service▲
Mais l'API vous permet également de mettre des callbacks en place, par exemple :
Il existe des callbacks pour tous les états possibles :
- setOnReady() - la tâche est prête ;
- setOnScheduled() - la tâche va être exécutée ;
- setOnRunning() - la tâche démarre son exécution ;
- setOnFailed() - la tâche a échoué ;
- setOnCancelled() - la tâche a été annulée ;
- setOnSucceded() - la tâche s'est correctement terminée.
Toutes ces méthodes sont appelées depuis le JavaFX Application Thread.
IV-F. Récupérer le résultat▲
Pour récupérer le résultat d'un service, il suffit d'appeler la méthode getValue() du service dans le listener ou le callback approprié. Ainsi le résultat de la tâche pourra être transmis à l'UI ou à un autre traitement.
IV-G. Récupérer la raison de l'échec▲
Pour récupérer la raison de l'échec d'un service, il suffit d'appeler la méthode getException() du service dans le listener ou le callback approprié. Cela permettra d'afficher l'erreur à l'utilisateur ou de la stocker dans un journal.
V. Utiliser une tâche▲
De manière générale, la classe Task sera uniquement manipulée par votre service et la majorité de son code s'exécutera dans son propre Thread, indépendant du JavaFX Application Thread. Voyons donc maintenant comment utiliser une tâche.
V-A. Notification de l'avancement▲
Depuis la méthode call() de la tâche, il est possible d'envoyer des informations vers l'UI via les méthodes updateProgress(), updateMessage(), etc. Les valeurs passées à ces méthodes seront transmises vers le JavaFX Application Thread.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
return new Task<Integer>() {
@Override
protected Integer call() throws Exception {
final int maxIterations = 1000000;
int iterations = 0;
for (iterations = 0; iterations < maxIterations; iterations++) {
// On envoie un nouveau message.
updateMessage("iteration "+ (iterations+1));
// On change l'avancement de la tâche.
updateProgress(iterations, maxIterations);
[...]
}
return iterations;
}
updateMessage("Done");
updateProgress(iterations, maxIterations);
};
Si trop d'appels à ces méthodes ont lieu dans un court laps de temps, il y aura agrégation des différents appels et seules les dernières valeurs seront transmises à l'UI. Ainsi certains messages peuvent être perdus et la progression peut sauter des valeurs si elle est trop rapide.
Dans le cas de boucles ou de progressions obtenues par calcul, il faut également faire attention au fait que updateProgress() générera une exception de type IllegalArgumentException si la valeur d'avancement devient strictement supérieure à la valeur maximum attendue.
V-B. Annulation▲
Comme nous l'avons vu précédemment, appeler la méthode cancel() du service met la tâche dans l'état CANCELLED, mais cela ne suffit pas en soi pour arrêter l'exécution de la tâche. Dans votre traitement, vous devez vérifier à intervalles réguliers la valeur retournée par la méthode isCancelled() de la tâche et interrompre le calcul en cours le cas échéant . Par exemple, la tâche suivante effectue 1 000 000 itérations et vérifie si la tâche a été annulée à chaque itération, interrompant la boucle si c'est le cas.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
return new Task<Integer>() {
@Override
protected Integer call() throws Exception {
final int maxIterations = 1000000;
int iterations = 0;
for (iterations = 0; iterations < maxIterations; iterations++) {
// Arrêt de la boucle si la tâche est annulée.
if (isCancelled()) {
break;
}
// On envoie un nouveau message.
updateMessage("iteration "+ (iterations+1));
// On change l'avancement de la tâche.
updateProgress(iterations, maxIterations);
[...]
}
return iterations;
}
};
V-B-1. Lors d'un appel bloquant▲
Lorsque l'on effectue un appel bloquant, par exemple en mettant le thread courant en pause dans une boucle, il est important de vérifier l'état de la tâche une fois que le thread courant est à nouveau actif. En effet, le thread peut se réveiller du fait que la tâche est passée dans l'état CANCELLED.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
return new Task<Integer>() {
@Override
protected Integer call() throws Exception {
final int maxIterations = 1000000;
int iterations = 0;
for (iterations = 0; iterations < maxIterations; iterations++) {
// Arrêt de la boucle si la tâche est annulée.
if (isCancelled()) {
break;
}
// On envoie un nouveau message.
updateMessage("iteration "+ (iterations+1));
// On change l'avancement de la tâche.
updateProgress(iterations, maxIterations);
[...]
try {
Thread.sleep(100);
} catch (InterruptedException ie) {
if (isCancelled()) {
break;
}
}
}
return iterations;
}
};
V-C. État d'une tâche▲
Il est également possible de superviser les changements d'état d'une tâche. À cet effet, il est possible de surcharger les méthodes scheduled(), running(), failed(), cancelled(), et succeeded() de la classe Task.
- scheduled() - la tâche va être exécutée.
- running() - la tâche démarre son exécution.
- failed() - la tâche a échoué.
- cancelled() - la tâche a été annulée.
- succeeded() - la tâche s'est correctement terminée.
Il n'existe pas de méthode pour l'état READY, car il s'agit de l'état par défaut d'une tâche à sa création.
Toutes ces méthodes sont appelées depuis le JavaFX Application Thread une fois que les propagations aux listeners ont été terminées.
V-D. Produire des résultats partiels▲
V-D-1. JDK 7▲
Dans le JDK7, Task ne produit qu'un seul et unique résultat : son résultat final. Cependant, il est assez facile d'ajouter la capacité de produire des résultats partiels en utilisant des propriétés JavaFX sur la tâche.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
public class IterationsTask extends Task<Integer> {
private final IntegerProperty partialResult = new SimpleIntegerProperty(this, "partialResult", -1);
public final int getPartialResults() {
return partialResult.get();
}
public final ReadOnlyIntegerProperty partialResultProperty() {
return partialResult;
}
[...]
}
Il faudra cependant, dans la méthode call(), prendre des précautions pour que les valeurs soient settées dans le JavaFX Application Thread et non pas dans le thread de la tâche. En effet, généralement des résultats partiels ne sont intéressants que dans le cadre d'un affichage dans une UI. Or, une fois affichées dans une scène, les propriétés des contrôles JavaFX doivent être uniquement accédées via le JavaFX Application Thread.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
@Override
protected Integer call() throws Exception {
final int maxIterations = 1000000;
int iterations = 0;
for (iterations = 0; iterations < maxIterations; iterations++) {
// Arrêt de la boucle si la tâche est annulée.
if (isCancelled()) {
break;
}
// ! La propriété doit être manipulée dans la JavaFX Application Thread !
final int it = iterations;
Platform.runLater(new Runnable() {
@Override
public void run() {
partialResult.set(it);
}
});
}
return iterations;
}
Il faut faire également attention au fait qu'ici, il n'y a pas de fusion ou agrégation des envois de valeurs partielles sur le JavaFX Application Tread. Cela peut donc provoquer une monopolisation ou une surcharge du thread par la tâche à cause du trop grand nombre de requêtes à Platform.runLater() et nous ramener à notre problème de blocage initial. Ici, cet exemple ne fait pas moins de 1 000 000 de requêtes à Platform.runLater() dans une boucle rapide sans aucune pause ! Cela peut faire que l'application cesse de répondre, ne puisse plus se redimensionner ou plante carrément, bref on perdrait tous les avantages liés à l'utilisation d'un service !
Il faudra donc penser à aménager des temps de repos en appelant Thread.sleep() à intervalles réguliers de manière à ce que le JavaFX Application Thread puisse continuer à s'exécuter et évacuer les événements en attente.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
@Override
protected Integer call() throws Exception {
final int maxIterations = 1000000;
int iterations = 0;
for (iterations = 0; iterations < maxIterations; iterations++) {
// Arrêt de la boucle si la tâche est annulée.
if (isCancelled()) {
break;
}
// ! La propriété doit être manipulée dans la JavaFX Application Thread !
final int it = iterations;
Platform.runLater(new Runnable() {
@Override
public void run() {
partialResult.set(it);
}
});
// Interragir ainsi avec le JavaFX Application Thread demande de lui laisser un peu le temps de respirer.
try {
Thread.sleep(50);
} catch (InterruptedException ie) {
if (isCancelled()) {
break;
}
}
}
return iterations;
}
On pourrait également modifier le code pour faire en sorte que les mises à jour de l'UI arrivent tous les 1000 éléments par exemple, de manière à réduire le nombre de mises à jour effectuées.
V-D-2. JDK 8▲
Le JDK 8 a ajouté la possibilité d'invoquer la méthode updateValue() dans le corps de la tâche pour mettre à jour le contenu de la propriété value de l'objet Task (et de son service parent). Il suffira alors de placer un écouteur de type InvalidationListener ou ChangeListener sur cette propriété pour être mis au courant de ses changements de valeur au cours du calcul.
La méthode updateValue() peut être invoquée depuis n'importe quel thread même celui dans lequel s'exécute la tâche. Tout comme les autres méthodes updateXXX(), les appels sont fusionnés lorsqu'ils sont trop nombreux, ce qui fait que certains changements de valeur peuvent être omis.
@Override
protected Integer call() throws Exception {
final int maxIterations = 1000000;
int iterations = 0;
for (iterations = 0; iterations < maxIterations; iterations++) {
// Arrêt de la boucle si la tâche est annulée.
if (isCancelled()) {
break;
}
// ! La propriété doit être manipulée dans la JavaFX Application Thread !
final int it = iterations;
updateValue(it);
}
}
return iterations;
}V-E. Utiliser une tâche dans un contexte non JavaFX▲
Vous pouvez être amené à utiliser une tâche dans un contexte non JavaFX, par exemple, dans le but d'effectuer des tests unitaires. De plus, la classe Task<V> hérite des interfaces Runnable et RunnableFuture<V>, il est donc tout à fait possible de la passer à un Thread Java normal pour exécution :
2.
final Thread imageLoadingThread = new Thread(imageLoadingTask);
imageLoadingThread.start();
Il est également possible de passer une tâche à un ExecutorService :
anExecutorService.submit(imageLoadingTask);
Cependant, vous serez rarement amené à utiliser ces cas de figure.
Attention, si vous utilisez Task dans un contexte où le JavaFX Application Thread n'a pas été initialisé, il ne faut pas appeler updateMessage() ou updateProgress() ou n'importe quelle autre méthode updateXXX() sous peine de générer des exceptions. De plus, cette approche peut ne pas fonctionner non plus avec des tâches produisant des résultats partiels telles que celles que nous avons montrées pour le JDK 7 puisqu'elles invoquent la méthode Platform.runLater() qui suppose que les runtimes JavaFX ont été correctement initialisés.
VI. Utiliser un service répétable▲
La classe ScheduledService, introduite dans le JDK8, permet de créer un service qui s'exécute de manière cyclique. Cette classe s'utilise exactement comme la classe Service, mais introduit de nouveaux concepts et propriétés. Lorsque le service s'exécute correctement, il redémarre automatiquement après un temps d'attente. Au contraire, lorsque le service échoue, le programmeur peut décider s'il se relance en fonction de plusieurs critères. Étant donné que le service se répète automatiquement de manière cyclique, il repasse régulièrement par tous les états possibles au cours de son exécution.
Attention, la gestion des durées par cette classe est indicative ; il ne faut pas utiliser ce genre de service pour des tâches demandant une précision extrême dans la gestion du temps.
VI-A. Délai avant l'exécution▲
Tout d'abord, la propriété delay permet de spécifier un temps d'attente avant le démarrage initial du service.
service.setDelay(Duration.seconds(5));
VI-B. Période d'exécution▲
La propriété period permet de définir le temps d'attente entre deux exécutions sans erreur. C'est-à-dire le temps qui s'écoule entre chaque moment dans lequel l'état du service entre en l'état RUNNING.
service.setPeriod(Duration.seconds(1));
Si la tâche prend plus de temps à s'exécuter que la durée spécifiée dans la période, ou si la période est vide (ex. : Duration.ZERO ou une durée indéterminée), le service se relance alors immédiatement après la fin de la tâche sans plus attendre. De plus, le service ne peut interrompre une tâche en cours si elle dépasse le temps d'attente indiqué pour la période.
VI-C. Gestion des échecs▲
Par défaut, en cas d'échec, le service se termine immédiatement. Il est possible de changer ce comportement en modifiant la valeur de la propriété restartOnFailure pour indiquer si le service doit se relancer en cas d'échec. Il est également possible de modifier la valeur de la propriété maxFailureCount pour indiquer le nombre maximal d'échecs supportés. La propriété en lecture seule currentFailureCount permet de connaitre le nombre d'échecs encourus par le service jusqu'à présent.
2.
service.setRestartOnFailure(true); // On continue l'exécution en cas d'erreur.
service.setMaxFailureCount(100); // Et au maximum on acceptera 100 échecs.
La propriété backoffStrategy permet de spécifier une fabrique à durées de type Callback<ScheduledService<?>, Duration> qui sera invoquée lorsque le service a échoué. Cela permet par exemple, d'augmenter, le temps d'attente entre chaque échec successif. Cette valeur sera ajoutée à la période du service lors du temps d'attente avant la prochaine tentative d'exécution. Cette valeur peut être plafonnée en utilisant la propriété maximumCumulativePeriod.
2.
service.setBackoffStrategy(service -> Duration.seconds(service.getCurrentFailureCount() * 5)); // On ajoute 5 secondes d'attente entre chaque échec.
service.setMaximumCumulativePeriod(Duration.minutes(10)); // Au maximum on attendra 10 minutes avant la prochaine tentative.
VI-D. Derniers bons résultats▲
La valeur de la propriété value du service sera réinitialisée à null avant chaque fois que le service se relance.
Il est donc plus intéressant de se pencher sur la propriété en lecture seule lastValue, qui contient la dernière valeur générée lors d'une exécution correcte de la tâche. Elle est initialement à la valeur null et ne sera mise à jour que lorsque la tâche s'exécute correctement. Il est donc possible de suivre ses changements de valeur en lui ajoutant un écouteur de type InvalidationListener ou ChangeListener.
VII. Conclusion▲
Vous savez désormais comment lancer une tâche de fond en JavaFX, ceci vous permettra de lancer tous vos traitements longs en arrière-plan de l'UI sans pour autant geler votre interface graphique.
VIII. Remerciements▲
Je tiens à remercier toute l'équipe du forum Développez ainsi que Mickael Baron et Gueritarish pour leurs suggestions et leurs relectures du présent article. Je tiens également à remercier Claude Leloup pour ses corrections orthographiques.