Support de la paire IA — JavaFX en pratique : de la dépendance au runtime
Ce support prolonge le cours en appliquant ses outils — Maven, le système de modules JPMS, la gestion de versions par étiquettes — à une véritable application graphique JavaFX. Il a été conçu pour fonder la paire de leçons consacrées à l’assistance automatisée par IA, dont il matérialise les engagements de maintenabilité. Il est construit sur le dépôt public ebpro/sample-javafx-client, qui contient deux petites applications (fxapp1, fxapp2) et un profil de build jlink, et dont le README fixe la version des modules JavaFX à 25.0.2 (provenance : README du tag v1.0.0 ; section 7). Statut à énoncer : JavaFX ne fait pas partie du JDK — ce sont des bibliothèques et des outils distincts, développés par le projet OpenJFX et livrés ici comme dépendances déclarées dans le POM (projet OpenJFX).
1. Objet et mode d’emploi : ce que le rendu montre, ce que votre poste montre
Une interface graphique paraît difficile à réutiliser dans un rendu automatisé : elle exige un écran. En réalité, presque tout le cycle de vie d’une application JavaFX — récupérer, déclarer ses dépendances, compiler, construire un runtime complet — s’observe sans aucune interface graphique. Le mécanisme en est simple : la compilation, la lecture des sources et le linkage jlink opèrent sur du bytecode et sur le graphe de modules ; ils n’initialisent pas le pipeline graphique. L’affichage n’intervient qu’à l’exécution de l’application, lorsque le toolkit se lie à un serveur graphique — étape que le conteneur de rendu ne peut pas franchir, et que ce support ne lui demande pas de franchir. Le tableau ci-dessous est le contrat d’exécution de tout ce qui suit.
Étape
Dans ce support (CI, sans écran)
Sur votre poste
Clonage du dépôt épinglé v1.0.0
oui
oui
./mvnw package (compilation, jar de module)
oui
oui
Lecture de module-info.java et des sources MVC
oui
—
./mvnw -q -P jlink package (runtime sur mesure)
oui
oui
Ouverture de la fenêtre (javafx:run, myapp)
non
oui
Rien n’est affirmé ici sans vérification : chaque commande présentée a été vérifiée dans le dépôt cloné, et tout chemin cité ici en est extrait.
2. Récupérer un support épinglé
Nous clonons la version étiquetéev1.0.0, et non la branche de développement : un document reproductible épingle aussi ses supports, exactement comme le cours épingle ses outils — c’est la même thèse de maintenabilité appliquée à un dépôt d’exemples. Le dépôt est public ; le clone passe donc en HTTPS, avec une boucle défensive de trois tentatives contre les faux départs réseau.
rm-rf /tmp/javafx-tpmkdir-p /tmp/javafx-tpcd /tmp/javafx-tpfor i in 1 2 3;dogit clone --branch v1.0.0 --depth 1 https://github.com/ebpro/sample-javafx-client.git &&breakecho"tentative $i échouée — nouvelle tentative"&&sleep 5 &&rm-rf sample-javafx-clientdonels sample-javafx-client
La racine contient notamment pom.xml, le wrapper mvnw, et src/ : un projet Maven standard, avec un wrapper — vous n’avez donc pas besoin d’installer Maven pour la suite.
Définition — Épinglement par étiquette
L’épinglement consiste à figer la base de travail d’un support sur une révision identifiée par une étiquette (tag) plutôt que sur une branche. Une étiquette désigne une révision immobile : elle ne bouge pas quand d’autres commits sont ajoutés, alors qu’une branche avance à chaque commit. Travailler sur l’étiquette v1.0.0 garantit donc que la lecture, la compilation et le linkage de ce support portent sur le même contenu, aujourd’hui et l’an prochain.
Exemple : la cellule exécutée ci-dessus clone --branch v1.0.0 --depth 1 ; la sortie ls attendue est la racine de cette révision figée (pom.xml, mvnw, src/), non celle de la branche de développement.
Cas limite : si aucune étiquette n’existe, le support retombe sur une branche — et devient mobile : deux rendus à deux dates peuvent construire deux contenus différents sans qu’aucune erreur ne le signale. L’absence d’étiquette est un défaut du support, pas une option du mode d’emploi.
Source : page de manuel gitglossary(7), entrée « tag object » ; la mécanique des étiquettes est enseignée dans la séquence Git du cours (sec-10), non réouverte ici.
3. Construire sans écran
Passez en revue l’arborescence des sources avant de compiler :
cd /tmp/javafx-tp/sample-javafx-clientfind src -type f |sort
Deux applications cohabitent dans un seul module : fxapp1 (quatre fichiers : une classe App, un contrôleur, un FXML, une feuille CSS) et fxapp2 (sept fichiers : cinq classes Java réparties en paquetages view et model, plus le FXML et la feuille CSS). Lançons la construction :
cd /tmp/javafx-tp/sample-javafx-client./mvnw-q package
Picked up JAVA_TOOL_OPTIONS: -XX:MaxRAMPercentage=25
WARNING: A restricted method in java.lang.System has been called
WARNING: java.lang.System::load has been called by org.fusesource.jansi.internal.JansiLoader in an unnamed module (file:/home/jovyan/.m2/wrapper/dists/apache-maven-3.9.9/3477a4f1/lib/jansi-2.4.1.jar)
WARNING: Use --enable-native-access=ALL-UNNAMED to avoid a warning for callers in this module
WARNING: Restricted methods will be blocked in a future release unless native access is enabled
WARNING: A terminally deprecated method in sun.misc.Unsafe has been called
WARNING: sun.misc.Unsafe::objectFieldOffset has been called by com.google.common.util.concurrent.AbstractFuture$UnsafeAtomicHelper (file:/home/jovyan/.m2/wrapper/dists/apache-maven-3.9.9/3477a4f1/lib/guava-33.2.1-jre.jar)
WARNING: Please consider reporting this to the maintainers of class com.google.common.util.concurrent.AbstractFuture$UnsafeAtomicHelper
WARNING: sun.misc.Unsafe::objectFieldOffset will be removed in a future release
La première exécution télécharge les dépendances : le wrapper Maven lui-même, puis les artefacts JavaFX et les bibliothèques tierces déclarées dans le POM. Cette phase peut durer plusieurs minutes ; les exécutions suivantes sont quasi instantanées grâce au cache local. Deux faits de construction méritent d’être notés avant toute interprétation. D’une part, le POM du tag compile avec la cible release 21 : c’est une propriété du dépôt épinglé (POM du tag v1.0.0), pas une consigne du cours, et rien ici ne demande à la corriger. D’autre part, le POM redirige le jar d’application vers target/modules (maven-jar-plugin, élément outputDirectory) — le jar est traité comme un module destiné à jlink, non comme un exécutable autonome : un jar autonome porte un manifeste qui nomme une classe principale et s’exécute par java -jar, tandis qu’ici le jar est une unité de linkage que jlink intègre dans une image ; la raison de cette destination — l’alimentation de jlink — est démontrée à la section 6. Inspectons le résultat :
cd /tmp/javafx-tp/sample-javafx-clientls target/ls target/modules/
La sortie attendue montre target/modules peuplé du jar produit. Notez enfin le décalage d’identification : l’étiquette Git v1.0.0 épingle le code source, tandis que le POM porte encore sa version de développement 0.1.0-SNAPSHOT — les deux mécanismes sont complémentaires, pas redondants : l’un fixe une révision du dépôt, l’autre nomme l’artefact que Maven publie.
4. JPMS : déclarer pour réutiliser
Le fichier qui distingue ce projet d’un simple dépôt de classes est en tête des sources. Lisons-le intégralement :
cd /tmp/javafx-tp/sample-javafx-clientcat src/main/java/module-info.java
/**
* Module definition for JavaFX applications.
* This module contains sample JavaFX applications that demonstrate
* various concepts and patterns in JavaFX development.
*/
module fr.univtln.bruno.samples.jfx {
// Required JavaFX modules
requires javafx.controls; // For JavaFX UI controls
requires javafx.fxml; // For FXML-based UI definitions
// Third-party dependencies
requires lombok; // For reducing boilerplate code
requires javafaker; // For generating sample data
requires org.slf4j; // For logging with SLF4J
// Java standard modules
requires java.logging; // For application logging
requires java.sql; // For database connectivity
// Module exports and opens for JavaFX app 1 (simple example)
exports fr.univtln.bruno.samples.jfx.fxapp1; // Export APIs
opens fr.univtln.bruno.samples.jfx.fxapp1 to javafx.fxml; // Allow FXML reflection access
// Module exports and opens for JavaFX app 2 (MVC architecture)
exports fr.univtln.bruno.samples.jfx.fxapp2; // Export main package
opens fr.univtln.bruno.samples.jfx.fxapp2 to javafx.fxml; // Allow FXML reflection access
// View layer exports and opens
exports fr.univtln.bruno.samples.jfx.fxapp2.view; // Export view components
opens fr.univtln.bruno.samples.jfx.fxapp2.view to javafx.fxml; // Allow FXML reflection access
// Model layer exports and opens
exports fr.univtln.bruno.samples.jfx.fxapp2.model; // Export model classes
opens fr.univtln.bruno.samples.jfx.fxapp2.model to javafx.fxml; // Allow FXML reflection access
}
Définition — Module JPMS et ses trois verbes
Un module est une unité de composition et d’encapsulation du système de modules Java (JPMS) : un paquetage de paquetages, plus un descripteur module-info.java qui déclare ses relations aux autres modules. Le descripteur s’analyse en trois verbes distincts :
requires — dépendance : le module courant a besoin des API du module nommé ; sans cette ligne, le compilateur et la machine virtuelle considèrent que la dépendance n’existe pas.
exports — offre : le paquetage nommé est accessible aux autres modules ; sans elle, ses types publics restent internes au module.
opens — ouverture à la réflexion : le paquetage nommé est rendu profondément accessible à un module donné (ici to javafx.fxml), sans quoi la réflexion d’un autre module sur ses types est refusée.
Exemple : la sortie exécutée ci-dessus applique les trois verbes — requires javafx.controls;, requires javafx.fxml;, requires lombok; (dépendances) ; exports … (paquetages offerts) ; opens … to javafx.fxml; (ouverture au chargeur FXML).
Cas limite : une déclaration peut survivre à son usage. La sortie exécutée montre un requires java.sql; alors que l’application ne touche aucune base de données — reliquat d’un état antérieur du dépôt. Ce n’est pas une erreur d’exécution : c’est une dette rendue visible par JPMS, donc attaquable — repérer ces dépendances devenues inutiles fait partie de la maintenance des dépendances explicites.
Source : documentation Java SE du paquetage java.lang.module (classe ModuleDescriptor, modélisation de module-info.java). Déjà vu en sec-11 sous l’angle des dépendances ; les trois verbes (requires/exports/opens) sont posés intégralement ici parce que la liaison FXML en dépend.
Il en résulte une propriété vérifiable ligne à ligne sur la sortie lue ci-dessus : la maintenance des dépendances commence par la mise en correspondance des déclarations du descripteur avec les usages réels du code.
Comparez le descripteur avec le POM : Maven y résout des artefacts (coordonnées, version, jar) ; module-info.java déclare des capacités (telle bibliothèque est nécessaire, tel paquetage est offert). Les deux documents se recoupent ici, mais ils répondent à deux questions différentes — « comment obtenir la bibliothèque ? » contre « qui dépend de quoi, à l’exécution ? ».
Deux liaisons méritent un développement, parce qu’elles engagent le comportement du système.
La liaison FXML–réflexion. Le chargeur FXML instancie les contrôleurs par réflexion. C’est précisément ce que la ligne opens … to javafx.fxml; rend possible. Sans elle, le refus est attendu à l’exécution du chargement : le chargeur lève une exception (javafx.fxml.LoadException, dont la cause est le refus d’accès réflexif du système de modules) et l’application ne démarre pas. Ce cas limite ne peut pas être exécuté dans le rendu — le chargement FXML appartient à l’étape d’affichage, exclue par le tableau de la section 1 — ; il est énoncé ici avec sa source, la spécification d’encapsulation du JPMS (paquetage java.lang.module, ouverture réflexive conditionnelle).
Le cycle de vie de l’application.App.java de fxapp1 montre le cycle de vie JavaFX : main appelle launch, qui rappelle init, puis start (chargement du FXML, création de la Scene, affichage du Stage), puis stop à la fermeture. Cet ordre est celui défini par la javadoc de javafx.application.Application (javadoc de la classe Application) ; il n’est pas observé dans le rendu, qui s’arrête à la construction.
fxapp1, l’application minimale
fxapp1 tient en quatre fichiers, ceux du listing find de la section 3 sous le paquetage fxapp1. Controller.java illustre la liaison déclarative : des champs annotés @FXML (dont taskInputField, taskListView et addButton) sont peuplés par le runtime, et la méthode initialize() les équipe de gestionnaires d’événements. Une liste de tâches, un champ de saisie, deux boutons — assez pour discerner chaque rôle, pas assez pour masquer le mécanisme.
5. MVC : fxapp2 sous la loupe
fxapp2 applique la même trame, mais en séparant les rôles en paquetages. Visualisons la structure :
cd /tmp/javafx-tp/sample-javafx-clientls src/main/java/fr/univtln/bruno/samples/jfx/fxapp2 src/main/java/fr/univtln/bruno/samples/jfx/fxapp2/view src/main/java/fr/univtln/bruno/samples/jfx/fxapp2/modells src/main/resources/fr/univtln/bruno/samples/jfx/fxapp2
MVC est un patron d’architecture applicative qui répartit le code en trois rôles distincts : le modèle — les données et les règles qui les régissent, indépendantes de toute interface ; la vue — la présentation de l’état du modèle ; le contrôleur — la traduction des entrées de l’utilisateur en demandes au modèle. Le critère du patron est le sens des dépendances : la vue et le contrôleur connaissent le modèle ; le modèle n’est censé connaître ni l’une ni l’autre.
Exemple : la sortie ls ci-dessus applique la répartition — model/ (Person, Page, PersonRepository), view/ (Controller), ressources (fxapp02.fxml, styles.css).
Cas limite : la frontière se juge à un critère observable, non à l’intention. Une valeur de couleur ou un calcul de présentation qui remonterait dans le contrôleur dissout le patron sans aucun message d’erreur : c’est exactement ce que les recherches grep de la section ci-dessous permettent de contrôler.
Source : Martin Fowler, Patterns of Enterprise Application Architecture, 2002, chapitre « Presentation Domain » (exposé moderne du patron) ; définition générale traitée en sec-05, non réouverte ici.
Trois étages, donc. Vérifions les trois points de couture entre eux — la vue ne connaît le modèle que par ces liaisons :
cd /tmp/javafx-tp/sample-javafx-clientgrep-n"fx:controller\|stylesheets" src/main/resources/fr/univtln/bruno/samples/jfx/fxapp2/fxapp02.fxmlgrep-n"PersonRepository\|@FXML" src/main/java/fr/univtln/bruno/samples/jfx/fxapp2/view/Controller.java |head-20head-16 src/main/resources/fr/univtln/bruno/samples/jfx/fxapp2/styles.css
Les sorties exécutées établissent la liaison dans les deux sens : le FXML désigne son contrôleur par fx:controller=…view.Controller et sa charte graphique par stylesheets="@styles.css" ; le contrôleur consomme le modèle (PersonRepository.newInstance()) sur les champs annotés @FXML que le grep montre. Le mécanisme de cette désignation n’est pas nouveau : c’est la réflexion ouverte en section 4 (opens … to javafx.fxml;) — le chargeur FXML instancie le contrôleur nommé par l’attribut, sans que la vue importe sa classe. La feuille CSS, elle, ne parle qu’en classes de style (header, toolbar, search-button).
Il en résulte une séparation contrôlable par les sorties ci-dessus : le contrôleur ne contient aucune valeur graphique (le grep ne montre que des références au modèle et des annotations @FXML), et le FXML ne contient aucun calcul (il ne déclare que des composants et des classes de style). Par conséquent, une modification de charte graphique peut se limiter au fichier CSS sans toucher aux sources Java ; le contrôle en est la recherche des valeurs de couleur dans les paquetages Java, qui ne doit rien retourner.
Lisez le modèle pour clore le tour — une entité minimaliste, identifiée par son UUID :
cd /tmp/javafx-tp/sample-javafx-clientcat src/main/java/fr/univtln/bruno/samples/jfx/fxapp2/model/Person.java
package fr.univtln.bruno.samples.jfx.fxapp2.model;
import lombok.*;
import java.util.UUID;
@Getter
@ToString
@AllArgsConstructor(staticName = "of")
@NoArgsConstructor
@EqualsAndHashCode()
public class Person {
@EqualsAndHashCode.Include
private final UUID uuid = UUID.randomUUID();
private String name;
private String address;
}
La sortie attendue montre dix-sept lignes : une partie des membres de Person (comportement d’égalité, accèsseurs, fabrique of) est générée par Lombok. C’est une observation du code déposé, non un outil enseigné dans ce cours. Le dépôt simulé PersonRepository est de même peuplé par la bibliothèque javafaker — fait du tag v1.0.0, sans incidence sur les notions de cette section.
6. Un runtime qui se build : le profil jlink
Dernier étage, et le plus directement vérifiable pour la maintenabilité : le POM définit un profil nommé jlink (plugin jigsaw-maven-plugin) qui assemble, à la phase package, un runtime Java taillé pour la seule application. Lançons-le :
cd /tmp/javafx-tp/sample-javafx-client./mvnw-q-P jlink package
Picked up JAVA_TOOL_OPTIONS: -XX:MaxRAMPercentage=25
WARNING: A restricted method in java.lang.System has been called
WARNING: java.lang.System::load has been called by org.fusesource.jansi.internal.JansiLoader in an unnamed module (file:/home/jovyan/.m2/wrapper/dists/apache-maven-3.9.9/3477a4f1/lib/jansi-2.4.1.jar)
WARNING: Use --enable-native-access=ALL-UNNAMED to avoid a warning for callers in this module
WARNING: Restricted methods will be blocked in a future release unless native access is enabled
WARNING: A terminally deprecated method in sun.misc.Unsafe has been called
WARNING: sun.misc.Unsafe::objectFieldOffset has been called by com.google.common.util.concurrent.AbstractFuture$UnsafeAtomicHelper (file:/home/jovyan/.m2/wrapper/dists/apache-maven-3.9.9/3477a4f1/lib/guava-33.2.1-jre.jar)
WARNING: Please consider reporting this to the maintainers of class com.google.common.util.concurrent.AbstractFuture$UnsafeAtomicHelper
WARNING: sun.misc.Unsafe::objectFieldOffset will be removed in a future release
Définition — Image de runtime (jlink)
Une image de runtime est un répertoire produit par l’outil jlink du JDK : une machine virtuelle complète limitée à un ensemble choisi de modules, plutôt que le JDK entier installé sur la machine. L’ensemble est calculé par résolution du graphe de modules : à partir des modules racines indiqués, jlink inclut leur fermeture transitive de dépendances — ici le graphe de module-info.java, qui entraîne les modules JavaFX requis.
Exemple : la vérification exécutée ci-dessous, test -x target/image/bin/myapp, confirme que l’image et son lanceur dédié (myapp, défini dans le POM par <launcher>myapp=…</launcher>) ont été produits ; ls target/image/bin en montre le contenu.
Cas limite : le lanceur est scellé au build. myapp embarque la classe principale connue de jlink au moment de l’assemblage ; après un changement de mainClass dans le POM, l’ancien myapp continue de lancer l’ancienne application. Il faut relancer ./mvnw -q -P jlink package pour que le lanceur suive — le runtime sur mesure est un artefact, et un artefact se régénère.
Vérifions que l’image de runtime a bien été produite, avec son lanceur dédié :
cd /tmp/javafx-tp/sample-javafx-clienttest-x target/image/bin/myapp &&echo"image OK"ls target/image/bin
image OK
java jrunscript keytool myapp
La sortie attendue est la ligne image OK, suivie du contenu de target/image/bin : l’application ne dépend plus d’un java installé sur le poste cible, elle transporte le sien. Devenu artefact de la phase package, rattaché à l’étiquette du dépôt, le runtime se vérifie sur le disque par la commande ci-dessus — ce qui distingue une propriété vérifiable d’une simple promesse.
7. Sur votre poste : ouvrir la fenêtre (bloc non exécuté par le rendu)
À faire — sur votre poste uniquement
Le README du dépôt fixe la condition : un JDK 23 ou plus récent (les modules JavaFX 25.0.2 l’exigent ; le POM compile avec release 21 — valeurs attribuées au README du tag v1.0.0, non des consignes du cours). La mise en place de ce JDK sur votre poste est détaillée dans le support d’environnement du cours (90_prerequis_environnement). Le rendu de ce support n’a pas d’affichage : les deux commandes ci-dessous ne sont pas exécutées ici. Deux chemins s’offrent à vous, selon que vous voulez développer ou livrer.
Développement — Maven lance l’application avec le JDK de votre poste :
# Bloc non exécuté par le rendu../mvnw javafx:run
Livraison — le runtime auto-suffisant construit à la section 6 :
# Bloc non exécuté par le rendu../target/image/bin/myapp
Critères de réussite (à observer sur votre écran) :
La fenêtre ouverte est celle de fxapp2 : liste de personnes paginée visible — le POM pointe mainClass vers fr.univtln.bruno.samples.jfx.fxapp2.App.
Exercice de lecture du POM : changez temporairement la propriété <mainClass> vers …fxapp1.App et relancez ./mvnw javafx:run ; critère atteint lorsque la fenêtre affiche la liste de tâches de fxapp1 (section 4). Rétablissez ensuite le POM : ce changement est un exercice de lecture, pas une modification à remonter.
Si vous aviez construit myapp avant le changement, relancez ./mvnw -q -P jlink package : sans cela, myapp garde la classe principale scellée au build précédent (cas limite de la section 6).
8. Ce que ce support apporte à la suite
Rien de nouveau n’a été introduit ici ; tout l’appareillage vient de briques déjà enseignées. Maven et les modules JPMS sont ceux du cours : le POM, le wrapper, le profil de build et module-info.java en sont l’application littérale (séquences Maven, sec-03, et JPMS, sec-11). Les tests que le dépôt pourrait porter relèvent des mêmes pratiques que celles du TP JDBC (sec-12). Le clonage épinglé par étiquette est celui du guide Git (sec-10). Ce que JavaFX ajoute n’est pas une technologie supplémentaire, mais un révélateur : une application graphique force les dépendances, les frontières et le runtime à devenir explicites, là où un programme en ligne de commande peut longtemps s’en dispenser.
Ce support établit trois propositions, chacune reliée à son critère d’observation :
Une dépendance non déclarée n’existe pas pour la machine : sans le requires correspondant, la compilation est rejetée (section 4).
Une frontière de rôles non tenue rend les modifications imprévisibles : les grep de la section 5 montrent exactement où passe la liaison modèle/vue/contrôleur, donc où une retouche graphique doit s’arrêter.
Un environnement qui n’est pas construit reste invérifiable : le test -x de la section 6 en donne la trace contraire sur le disque.
Ces trois propositions convergent vers la position que les leçons sur l’assistance automatisée réutilisent : maintenir un système, c’est rendre ses engagements explicites et vérifiables.