Comparatif AWT/Swing/SWT/JavaFX

Accès rapide :
L'AWT (Abstract Window Toolkit)
L'API Swing
JavaFX : la dernière née des API graphiques proposées par le Java SE
SWT : une autre librairie de mise en oeuvre d'interfaces graphiques

Nous allons, dans ce tutoriel, nous intéresser à la mise en oeuvre d'interfaces graphiques en Java via l'API Swing. Comme nous allons le voir, il vous est possible de créer toutes sortes d'interfaces, et d'y inclure tous types de composants : des boutons, des cases à cocher, des zones de saisie de texte, ... Mais vous pourrez aussi y inclure des composants plus complexes : des menus, des arbres déroulants, des boîtes de dialogue pour choisir des fichiers, des couleurs, ... Nous allons, tout au long des chapitres suivants, présenter les principales possibilités qui vous sont offertes.

Mais avant d'aller plus loin il nous faut être capable de faire un choix. En effet, trois API de mise en oeuvre d'interfaces graphiques vous sont proposées par l'environnement Java SE (Standard Edition) : l'AWT (Abstract Window Toolkit), Swing et JavaFX. Quels sont les avantages et les inconvénients de chacune de ces deux librairies ? Notez aussi que le consortium Eclipse (en partie géré par IBM) propose aussi sa propre API de mise en oeuvre d'IHM : SWT. Et encore une fois, laquelle choisir ?

L'AWT (Abstract Window Toolkit)

L'Abstract Window Toolkit est historiquement la première qui vous fut proposée. Dès le JDK 1.0 (ancienne terminologie pour parler du Java SE), vous pouviez déjà l'utiliser. La contrainte de l'AWT, ou l'avantage (c'est à double tranchants), c'est que Java fait appel au système d'exploitation sous-jacent pour afficher les composants graphiques. Pour cette raison, l'affichage de l'interface utilisateur d'un programme peut diverger sensiblement : effectivement, chaque système d'exploitation dessine à sa manière ses différents éléments graphiques (bouton, zone de texte, ...). Attention, l'AWT garantie que la fonctionnalité recherchée sera fournie dans tous les cas, même si elle pourra être présentée différemment : l'exemple le plus classique est celui de la liste déroulante qui peut effectivement se présenter de manières très distinctes d'un OS (Operating System) à un autre.

Le principal avantage à utiliser l'AWT réside dans les performances en termes d'affichage : comme c'est l'OS via du code C ou C++ (très certainement) qui affiche votre interface graphique les temps de réponse sont très rapide. Il y a aussi un inconvénient à utiliser cette librairie : l'AWT ne contient que des composants graphiques qui existent sur tous les OS. Du coup, on peut affirmer que cette librairie est relativement pauvre, comparativement aux autres qui vont vous être présentées ci-dessous.

L'API Swing

Cette librairie de mise en oeuvre d'interfaces graphiques a été intégrée dans l'environnement Java SE depuis sa version 1.2 (anciennement JDK 1.2). L'approche Swing est différente : une application doit fonctionner et se présenter à l'identique, ce qu'elle que soit la plate-forme considérée. Pour ce faire, ce n'est plus l'OS qui va pixeliser les différents éléments graphiques de vos IHM, mais bien l'API Java Swing. Du coup, si un composant graphique n'est pas proposé par un système d'exploitation, il n'y a pas de soucis : Swing vous le proposera quand même. Donc un point très positif à utiliser Swing réside dans la richesse des composants proposés (en nombre, largement supérieur à ceux proposés par la librairie AWT).

Un autre point positif réside dans le fait que Swing ne vous propose pas un unique look graphique : vous en avez plusieurs et ce nombre augmente progressivement. Le dernier look en date proposé par Java est le look Nimbus, fort sympathique. Notez aussi, qu'outre les looks proposés en standard par l'environnement Java SE, vous pouvez trouver sur Internet de nombreuses autres implémentations de look pour vos programmes Java (certains gratuits, d'autres payants). A titre d'exemple, voici deux captures d'écran montrant une même application, mais qui utilise deux looks distincts (Metal et Nimbus).

Par contre, il y a un point important à signaler : une application codée en Swing consommera beaucoup plus de ressources (mémoire et CPU) qu'une application codée via l'AWT. Néanmoins, plus le temps passe et plus l'augmentation de la puissance de calcul des CPU permet d'absorber ce problème. A ce jour, une application graphique complexe, codée en Swing, peut être utilisée sans trop de désagrément (au pire, de temps à autre, une phase de garbage collector peu se faire sentir).

Notez que les deux librairies (l'AWT et Swing) partagent en fait un certain nombre de points communs. En premier lieu, toutes les classes de composants graphique de Swing héritent, directement ou indirectement, d'une classe de l'AWT (par exemple, la classe Swing javax.swing.JFrame hérite de la classe java.awt.Frame). De plus, les mécanismes de positionnement des composants graphiques dans un conteneur (les fameux layouts) sont, en bonne partie, communs entre l'AWT et Swing. Enfin, la gestion des événements (basée sur le pattern de listener) est elle aussi commune, entre les deux APIs : par exemple, les classes et interfaces utilisées pour la gestion de événements liés à la souris (java.awt.event.MouseListener, java.awt.event.MouseMotionListener, ...) sont utilisées telles qu'elles dans Swing. Le tout, facilitant le passage, pour un développeur, d'une librairie à l'autre. Assez souvent, le nom d'une classe Swing correspond au nom de son homologue AWT avec une lettre J ajoutée en première position : par exemple javax.swing.JButton correspond à java.awt.Button, javax.swing.JFrame correspond à java.awt.Frame, ...

Swing n'a quasiment plus évolué depuis le Java SE 7.0 et seuls des correctifs de bugs y sont actuellement effectués. Notez aussi qu'une interface graphique produite via Swing sera très bien adaptée pour une application type « client lourd » traditionnelle, par contre elle sera beaucoup moins adaptée à une utilisation sur écran tactile tels que ceux utilisés sur vos smartphones ou tablettes.

JavaFX : la dernière née des API graphiques proposées par le Java SE

JavaFX est désormais l'API d'interface graphique principale du Java SE. Dans sa conception, elle est plus moderne que Swing et permet de produire des interfaces graphiques pouvant facilement être utilisées sur différents types d'écrans (écran standard de PC, smartphone & tablettes et applications Web).

JavaFX ressemble, à plusieurs égares, à certaines API des développement Web dans le sens ou les vues peuvent se définir via un formalisme XML (FXML), le code Java ne contenant quasiment plus que les gestionnaires d'événements.

SWT : une autre librairie de mise en oeuvre d'interfaces graphiques

Pour information, il existe une autre librairie de mise en oeuvre d'IHM très couramment utilisée : SWT (Standard Widget Toolkit). Elle est proposée par le consortium Eclipse (le même qui développe l'IDE de développement Java du même nom). On peut dire que SWT est très proche de Swing et qu'elle propose plus ou moins les mêmes types de composants graphiques.

Tout comme Swing, SWT support la notion de look'n feel (on parlera plutôt de thème avec SWT) : il est donc possible d'affiner le look de vos applications en fonction de vos préférences.