Rechercher
 

Comparatif AWT/Swing/SWT

La gestion des threads Gestions d'événements



Accès rapide :
   L'AWT (Abstract Window Toolkit)
   L'API Swing
   SWT : une autre librairie de mise en oeuvre d'interfaces graphiques

Nous allons, dans cette section, nous intéresser à la mise en oeuvre d'interfaces graphiques en Java. 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 case à cocher, des zones de saisie de texte, ... Mais vous pourrez aussi y inclure des composants plus complexes : des menus, des arbres déroulant, 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, deux API de mise en oeuvre d'interfaces graphiques vous sont proposées par l'environnement Java SE (Standard Edition) : l'AWT (Abstract Window Toolkit) et Swing. 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 IHM. 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 deux 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 pixéliser 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 qu'en vérité, Swing ne vous propose pas un unique look graphique : vous an 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 look 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).

Look and feel Metal

Look and feel Nimbus

Par contre, il y a un point important à signaler : une application codée en Swing consommera plus (bien 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 commun. 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 commune, elle aussi, 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.

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). D'un certain point de vue, on peut dire de SWT se situe entre les deux librairies précédemment présentées. Effectivement, si l'OS propose le composant considéré, SWT demande alors à l'OS de l'afficher. Dans le cas contraire, SWT prend en charge sa pixelisation.

Il en découle qu'une IHM SWT ne se présente pas de la même manière d'un OS à un autre. Un petit défaut que l'on peut reprocher à la librairie SWT, est qu'elle n'est pas directement contenue dans l'environnement Java SE. Pour cette raison, la librairie SWT ne sera pas étudiée dans ce tutorial, mais sachez que son utilisation est néanmoins très agréable.



La gestion des threads Gestions d'événements