Dans une application, la partie graphique est aussi importante que la partie traitement car c’est la première qui reste la plus visible pour l’utilisateur. Une application dont l’interface utilisateur n’est pas claire sera fatalement peu utilisée. Nous allons voir quelles sont les librairies Java à votre disposition pour réaliser l’interfaçage ainsi que certains outils, libres ou payants, que vous pourrez utiliser.
Aujourd'hui, la majorité des développements graphiques en Java utilise Swing. Au début, il y avait AWT (Abstract Windowing Toolkit). Cette API graphique est compatible avec toutes les versions de Java, y compris Java Mobile Édition. Les composants sont dits " lourds " car ils
sont dessinés et contrôlés par le système et non par Java. C'est pourquoi AWT utilise assez peu de ressources, pourtant il se fait vieux et rend difficile l’utilisation d’architecture en couches. Le principe du MVC (modèlevue-contrôleur) ne peut pas être respecté en AWT. Il se limite aux composants communs à tous les systèmes, il faut donc souvent les personnaliser. AWT reste un choix pour les systèmes limités. Une évolution de l’interface Pour lui succéder, Sun a entrepris de développer la librairie Swing. Respectant l'architecture vue-contrôleur, Swing est un standard complet. Aspect décisif, les composants Swing sont légers (c'est à dire dessinés par Java2D et contrôlés en pur Java). De cette caractéristique qui reflète l'objectif "Write once, run everywhere" découlent plusieurs inconvénients :
les composants manquaient d’esthétique, le rendu pouvait paraître lent, … Swing consomme beaucoup de mémoire mais est-ce aussi lent qu'on le dit ? Codée en pur Java et n’utilisant pas de fonction native, il est normal qu'elle ne soit pas aussi rapide qu'une API graphique native au système d’exploitation. Mais la puissance des ordinateurs évoluant rapidement, cela se fait de moins en moins ressentir. Le choix d’objets graphique dessinés directement par Java2D fait à la fois la force et la faiblesse de Swing : la portabilité du même code quelle que soit la plate-forme de destination est possible grâce à Swing, cependant, la contrepartie de cette portabilité était un manque de réactivité des applications graphiques Java. L'utilisateur est souvent frustré lors de l'utilisation pour quelques dixièmes de secondes de latence qui sont le reflet de l'architecture même de Swing. Cette impression est provoquée, par exemple, lors d'un clic de bouton, si ce dernier effectue quelque chose de long, comme un accès sur un réseau, il faut jouer avec les threads pour éviter que l'interface ne se gèle et pose des problèmes de rafraîchissement.
