Discussion :

[DerMond_B.A]

Salut les développeurs des clients lourds,
je compte concevoir une application lourde en Java, et j'aimerai avoir vos avis par rapport à son côté graphique IHM.
Qu'est ce que vous me conseillez selon votre expérience ?
Bien sûr j'ai fait des recherches sur le net et parmi les résultats que j'ai eus, ce lien :
http://www-igm.univ-mlv.fr/~dr/XPOSE...swt_swing.html
Je vous remercie d'avoir lu mon message

[joel.drigo]

Salut,

Il y'a (au moins) une troisième alternative (l'article que tu as lu doit dater un peu) : JavaFX.

1. Swing est pur Java, inclus dans le JDK, donc directement exploitable, rien à importer de particulier (plus tout à fait avec Java 9). Swing est assez simple d'utilisation, et très puissant. Son principal défaut est sa principale qualité : être pur Java. Ce qui signifie qu'il sera moins intégré dans l'environnement (il y a bien des look and feel qui permettent d'avoir quelque chose de ressemblant à une application native, mais il faut les trouver, voire les acheter, et on peut toujours avoir des légères différences). Avec un look and feel standard, l'interface n'est pas très jolie, parait vieillotte, sauf si on passe un temps considérable à fignoler.
2. SWT justement est plus intégré, plus native, mais obligé d'embarquer des parties natives (dll par exemple sous windows), ce qui rend le déploiement un peu moins simple. Et la gestion de la compatibilité avec l'OS, en particulier sous Mac, peut être un peu compliquée parfois (il y a un réel compromis à réfléchir entre la garanti que Swing fonctionne même en cas d'upgrade d'OS, mais ne sera pas intégré, et SWT mieux intégré, mais pas forcément avec la toute dernière version de l'OS Apple - en particulier si on est obligé de mixer du Swing et du SWT). La programmation en elle-même est plus complexe : il faut bien penser à libérer ses ressources, sinon, on risque l'épuisement de handle système. Pour les composants de formulaire, ce n'est pas spécialement compliqué, mais pour la gestion de ressource (image, couleur, police, etc.), ça peut devenir assez tricky si on veut économiser de la mémoire en réutilisant des ressources à plusieurs endroits. Même avec JFace (qui est absolument indispensable si on veut faire des tables ou des arbres facilement), il n'est pas aussi aisé de faire des interfaces avec des rendus non standard (les renderers de Swing sont bien plus pratiques/puissants que ce propose Swing). A noter que l'approche de gestion ressemble à du MVC sans en être complètement à mon avis. Toutefois l'utilisation de l'API de bindings peut permettre de ne pas être gêne par cet aspect, mais ça fait encore une couche de plus à connaître (c'est pour moi un gros souci de SWT : il y a toujours une API supplémentaire pour permettre de faire quelque chose de mieux ou plus simple, ou de faire simplement, mais c'est une API de plus).
   Personnellement, le seul point où je trouve que SWT enterre SWING est l'agencement. Non seulement les layout managers sont plus simples d'utilisation, mais les layouts standards sont directement adaptés pour faire facilement et proprement du formulaire responsive (il y a l'API FormLayout de JGoodies qui comble cette lacune de Swing). Il est également beaucoup plus facile de développer son propre layout manager (disons que c'est plus basique, donc plus simple à comprendre).
   A noter que l'écosystème est à mon avis plus développé sur SWING : on trouve plus facilement de nombreux composants pour faire ce qu'on veut (voir par exemple, la bibliothèque JIDE). Avec SWT, il y a bien Opal, mais c'est plutôt limité. Il y a également Nebula, mais c'est surtout écrit pour être utilisé dans le cadre d'une application Eclipse RCP. Si l'utilisation de SWT et JFace est assez facile en standalone, je n'ai jamais essayé de faire la même chose avec Nebula. Pas sûr que cela soit aussi simple. En tout cas, ceci peut amener à être obligé de mixer Swing et SWT, et donc d'avoir des soucis (en particulier sur Mac).
3. JavaFX est plus récent, plus réactif, et le rendu est gérable en css. On se rapproche donc ce qu'on peut en faire en web. Le résultat est plus joli, plus moderne. Et c'est probablement plus facilement abordable par quelqu'un qui a déjà fait du RIA. Mais je dirais que le principal défaut est probablement d'être sorti beaucoup trop tard, alors que le développement de client lourd n'étaient plus autant pratiqué. Il y'a donc moins d'API tiers, avec des composants particuliers. Je n'ai aucune expérience sur l'utilisation de JavaFX, donc ne peux dire grand chose sur ce qu'on peut faire réellement avec et ce qui est disponible pour l'enrichir.
4. Il y a d'autres système que je ne connais que vaguement de nom. Y compris des systèmes de génération automatique d'UI.

[Mickael_Istria]

Je suis plutot d'accord avec Joel.
Par contre, dans ton message initial, tu parles de creer une appli lourde. Plutot que de se focaliser sur le toolkit graphique, ca pourrait aussi etre interessant d'evaluer differents frameworks RCP (Eclipse RCP, NetBeans RCP, JavaFX+e4...) qui fournisse en plus de la partie graphique des concepts vraiments forts pour les grosses applis: extensibilite, "workbench" qui permet de faire du drag'n'drop de views/panels, services pour la selection, la gestion de fichiers et compagnie... Tout ces services sont des plus gros differentiateurs pour toi en tant que developpeur que le toolkit graphique.

[spidetra]

Globalement d'accord avec les deux posts précédents.
Par contre le lien que tu as donné en référence est de 2004, et tu peux le considérer comme obsolète.

Pour faire du client lourd en Java, tu as aujourd'hui deux technologies majeures de composants graphiques :
- JavaFx
- SWT

Oublie Swing, c'est vraiment une techno obsolète. La techno officielle d'Oracle est JavaFx depuis le Jdk8.

D'accord avec Joel, JavaFx est une techno qui est arrivé tardivement à un moment ou les clients lourds n'ont plus trop la côte.
J'ai l'impression qu'elle a été assez peu adopté par la communauté.

Tu en dis assez peu sur ton projet, et c'est donc difficile de te conseiller.

Actuellement je travaille sur un gros projet de client lourd : JavaFx + pur e4.

ça marche bien, bonne intégration des deux technos. Nous n'avons plus les limitations d'IHM liés aux composants SWT.
La librairie des composants SWT est vraiment pauvre, même en rajoutant les quelques composants Nébula.

Notre projet c'est un client lourd, de chez lourd. On s'embarque tout le framework Eclipse RCP + EMF, GEF etc...
ça demande aussi des compétences importantes dans la maîtrise de ces technos et leurs intégrations.

Pour rejoindre Mickael, tu dois t’interroger sur tes besoins.
As-tu besoins d'un framework RCP : eclipse ou autre ?

Si tu choisis un framework du type e4 + JavaFx, il faut avoir conscience que le niveau de complexité est beaucoup plus important qu'une simple application JavaFX.
Est-ce que cette complexité supplémentaire est justifiée dans le cas de ton projet ?

[DerMond_B.A]

Salut et un grand à vous tous pour vos précieuses remarques et informations auxquelles je n'ai pas pensées vu mon expérience si modeste dans ce domaine de RIA.
Au sujet de mon projet, que je considère un challenge personnel, il s'agit d'une application qui facilite le travail des inspecteurs de l'enseignement en terme de rapports de visite (pendant le cours des enseignants), de l'emploi de temps des enseignants que chaque inspecteur contrôle (à chaque début de l'année scolaire) et bien d'autres aspects ...
Ça serait une application qui s’intéresse principalement à un seul acteur (l'inspecteur).