Discussion :

[hugo123]

Devrait-on faire un client lourd en Java ?


Il y a peu j'ai écrit un petit billet sur mon blog sur ce sujet. Je le partage avec vous en intégralité pour avoir une discussion avec des membres de développez.com.

Ayant bossé en Java je me suis heurté à Swing comme on peut se heurter à un mur. Ouch, quand on vient du Web on déguste fort avec Java et son API pour client lourd. Pour autant, la techno est elle valable ou non, et que vaut-elle par rapport à J2EE ?

Swing avant 2007

Avant 2007 Sun a clairement focalisé son attention sur J2EE ce qui leur a permis de gagner en popularité. Le nombre de frameworks existant et la richesse des librairies proposées lui ont permis de s'assoir durablement comme "langage pour faire du Web".

Seulement voilà, à côté de ça J2SE, la partie réservée aux postes de travail, a par contre était délaissé. Pourquoi ? Selon James Gosling, la faute au conflit qui opposait alors Sun et Windows sur le déploiement de la JVM Windows sur les postes par défaut. Sun n'aurait pas souhaité s'investir dans J2SE tant que Windows proposerait sa JVM.

De l'avis du créateur de Java : "Aujourd'hui, Java sur le poste client n'est pas à la hauteur" et ce constat est facile à confirmer :

• aucun framework Swing de réelle envergure : pas d'équivalent à JSF, Struts, Wicket, Tapestry etc... si on compare a J2EE
• peu de librairies de composants : Swingx reste experimental.
• un système de look and feel trop complexe, pour preuve le peu de boites capable de créer le leur en comparaison avec le nombre capable de créer des CSS

La difficulté de Swing, notamment la maitrise de la gestion événementielle et de l'EDT n'en font pas une partie de plaisir et au final ce n'est pas étonnant de trouver essentiellement des librairies payantes (Jide par exemple qui est très bon) alors qu'on peut en trouver gratuitement à foison en J2EE.

Swing depuis 2007

Mais voila, depuis 2007 Sun semble vouloir revenir sur J2SE :
- James Gosling, créateur de Java met en avant JavaFx
- Swingx tente d'apporter du neuf avec objectif d'être intégré en Java 1.5
- Aerith déjà présenté en 2006 devient open source , et oui, effectivement c'est une IHM qui déchire pas mal. Un jnlp existe sur leur site, il faut tester avec le login romainguy.
- Romain Guy qui s'était fait connaitre sur Aerith publie avec Chett Haase un très bon bouquin : Filthy rich clients

Soyons honnête toutefois, le bouquin filthyrichclients s'il démontre qu'on peut faire du très bon travail avec Swing met aussi en évidence que ça ne s'adresse pas à tout le monde. Certaines notions comme le double buffering, les problématiques d'accélération matérielle, les notions de Composite ou de transformation d'images sont très techniques et mettent en oeuvre des notions mathématiques qui ne s'adressent pas à monsieur tout le monde. Qui n'a pas galéré des heures sur des problèmes de glitch graphique, de pixels gris etc... ?

Et aujourd'hui ?

Et aujourd'hui 2009, cela me parait toujours moins rose.

• JavaFx peine à décoller et son API n'est pas toujours pas stable (compatibilité 1.1 et 1.2 qui laisse à désirer). A côté de ça, ses concurrents directs comme Flex sont en plein boom avec notamment un sdk qui vient de sortir sur Eclipse
• aucun framework n'a émergé pour cacher la complexité des concepts nés dans Aerith (* voir plus bas pour nuancer cette affirmation)
• Swingx est tellement peu mis à jour qu'il continue toujours à cibler Java 1.5, version en fin de support depuis cette année...

Pourquoi ce manque d'investissement de Sun depuis 2 ans ? Le rachat d'Oracle n'y serait pas étranger ou bien est-ce simplement que 2 ans reste un délai très court ? Nous verrons bien.


Mais personnellement j'ai tendance à être sceptique d'autant que la grande force de J2SE qui était la richesse de ses widgets et la réactivité de son interface est désormais sévèrement concurrencé par les interfaces Web. GWT ou JSF avec IceFaces apportent désormais la même richesse aux webapps et pour un cout nettement moindre.

En conclusion, je ne dénigre pas Swing et je pense que sa chance de survie va reposer comme beaucoup d'autres technologies sur la capacité à la communauté à proposer des outils, des composants, des best practices afin de cacher la complexité du langage. Mais à l'heure actuelle, si on me donne le choix, je partirais pour ma part sur du J2EE classique.


(*) En fait, il existe bien une librairie assez avancé qui permet de masquer la complexité. J'ai d'ailleurs un second billet sur ce sujet qui parle de substance et laf-widget : http://hakanai.free.fr/index.php/the...ubstance-swing



Source : Le post sur mon blog

[OButterlin]

Spécialiste des applications web mais depuis 1 an "scotché" sur une application swing, je pense comprendre ce que tu veux dire...

Pour moi, je ne pense pas que les 2 technos s'affrontent, le client lourd java aura toujours l'avantage pour la réalisation d'applications en forte relation avec les ressources de la machine (PC) ou dans le cadre d'applications ultra-confidentielles (sécurité).
Pour le reste, les applications web sont très certainement l'avenir de tout le reste, le côté j'utilise sur n'importe quel poste et de n'importe où dans le monde a de gros atouts.

D'un point de vue développement, là, je suis d'accord avec toi, swing est nettement plus compliqué qu'un framework jee comme jsf, et d'un point de vue look, une bibliothèque comme RichFaces est vraiment géniale et procure une ihm proche d'un client lourd.
Ce que je trouve le plus pénible dans swing, ce sont les layout (quelle m.... !). On va dire que c'est par inexpérience, mais quand même... c'est galère, rien n'est simple... (Vive le HTML, pour dire )

Par contre, swing n'est pas opposé à jee, on peut très bien utiliser (et d'ailleurs ça se fait couramment) des "éléments" jee dans une application swing (jdbc, rmi, ejb, jpa, jndi, etc...)

[bouye]

Je suis d'accord avec James euh avec Hugo. Marrant d'ailleurs, je me suis plusieurs fois fait rabrouer pour avoir soulever de telles opinions sur le forum interne.

Déjà on oublie trop souvent que Sun n’a pas développé Swing. Ils en ont hérité de Netscape qui l’a développé courant 1996 et qui leur a refilé le bébé début 1997 (c’est dire si l’API date). Durant la période 1998-2004, ils n’ont guère fait plus que ce qu’ils font maintenant : de la maintenance pour corriger quelques bugs et des problèmes de fonctionnalité. Le plus gros des développements semblent avoir été fait côté AWT pour plusieurs raffinements du support du DnD, des améliorations de la gestion de l’EDT, etc. , et pas mal d’améliorations coté 2D dont Swing a hérité indirectement donc. Très peu de choses ont été ajoutées à Swing même, ce qui est plutôt étonnant car avec une API pure Java on aurait eut tendance à croire qu’on aurait vu des composants portables 100% pur Java et fourni en standard dans chaque JVM fleurir à foison. Apparemment Sun ne semble pas avoir d’équipes dédiées en ergonomie et en R&D des interfaces graphiques comme peuvent en avoir Microsoft et Apple.

Pour être précis dès 2005, il y avait une volonté réelle de pousser à nouveau sur le client desktop et il y avait alors chez Sun un réel potentiel/vivier de personnes impliquées et très dynamiques (Scott Violet, Chett Haase, bien sur Romain mais aussi bien d'autres) qui semblaient vouloir enfin pousser fort coté client et développer Swing pour le remettre à plat/au gout du jour. Seulement voila alors qqun a eut l'idée de créer F3 (ce qui n'est pas une mauvaise idée en soit) et là, chez Sun, ca a fait *tilt* et ils ont soudainement décider d'aller concurrencer Flash sur son propre terrain voir même au-delà sans y mettre les même moyens qu’Adobe .

En plus leurs ressources étant limitées comme d'hab, ben ils ont mis tous leurs œufs dans le même panier et les ressources internes ont été divisées entre le devel de F3/JavaFX d'une part et le passage en OpenSource d'autre part... tout comme aujourd'hui elles sont accaparée par le devel du JavaStore et le port/adaptation de JavaFX sur toutes les plateformes+extension/stabilisation de l'API/lib sans compter la crise puis la fusion d'avec Oracle qui sont venues arrêter certains projets (pu de fond) ou les ralentir. Cela se voit aussi un peu dans les drastiques réductions de fonctionnalités pour Java 7 par rapport aux choses initialement prévues (sans parler du nouveau planning des sorties des JVM post Java 6 qui, à peine annoncé, n'est plus respecté) et tout cela a les mêmes causes : manque de ressources humaines et financières, mauvaise stratégie cote client desktop (je n'ai rien a redire cote serveur et je ne connais pas le cote client mobile).

Bref, depuis, les ténors de la SwingTeam et de la team 2D sont allés voir ailleurs. Des projets sponsorisés comme SwingX sont loin d'avoir exploré tout ce qui devait être couvert initialement et seule une infime portion sera incluse dans Java 7. Et ne parlons pas des initiatives qui pourraient être utiles du genre Swing 2 etc.

PS : SwingX vient de passer en 1.6 only http://weblogs.java.net/blog/rah003/...gx-16-released

[nouknouk]

Perso, j'ai toujours du mal à comprendre pourquoi essayer de comparer des choses qui me semblent incomparables: les frameworks J2EE (struts, ...) et Swing.

C'est amha un peu comme si on voulait comparer une station Citrix et un PC de bureau survitaminé et en conclure que "ah ben Citrix ça a vraiment du retard: on peut pas faire tourner FarCry".

Rien de 'poilu' dans mon message, juste deux constats: on ne fait pas les mêmes choses dans une philosophie 'client léger' et 'client lourd', et (plus globalement) l'ensemble de l'informatique ne se résume pas à des webapps.

Dans une moindre mesure, vouloir comparer JavaFX et Swing, c'est amha également un peu comme vouloir comparer Flash et Qt: il y en a un qui est pensé pour faire du multimédia, orienté "applets internet" et hautement graphique ; l'autre pour faire des IHM d'applications classique type 'client lourd'.

Il y a bien des domaines pour lesquels ils peuvent éventuellement entrer en 'concurrence', mais l'un et l'autre ne poursuivent pas le même but et sont donc architecturés chacun autour d'une 'philosophie' totalement distincte.

[OButterlin]

C'est amha un peu comme si on voulait comparer une station Citrix et un PC de bureau survitaminé et en conclure que "ah ben Citrix c'est pas super, on peut pas faire tourner FarCry.

Non On ne peut pas faire tourner FarCry ??? Ah ben c'est vraiment pas super

Mais sur le fond, je suis d'accord avec toi, les 2 technos ne s'opposent pas, elles se complètent.

Il n'en demeure pas moins que swing est compliqué et n'a pas beaucoup évolué depuis qu'il existe...

[hugo123]

Si je les compare c'est qu'aujourd'hui je travaille sur des applis ou le choix est entre les deux est judicieux.
Aujourd'hui a faire du client-serveur ces deux technos me paraissent largement comparables :

- la philosophie des applis web aujourd'hui est bien de concurrencer le client lourd, Cf google wave face a outlook, les éditeurs de texte online et toute la mode du Saas actuel.

- entre du swing via JavaWebstart ou du Web pur la cible est bien la même, déploiement léger

Petite parenthèse :
J'ai même déjà vu des applis desktop embarquer un serveur web de facon transparente pour proposer une ihm web.

Quand a JavaFx, selon le mot même de ces auteurs il n'est qu'un Swing2 sans l'admettre. Il permet tout autout de faire du desktop que de faire du client léger "a la flash" en simplifiant la partie Webstart. D'ailleurs on peut faire tourner des composants Swing dedans.


Mais justement, quand tu dis "on ne fait pas les mêmes choses dans une philosophie 'client léger' et 'client lourd'" ca m'intéresse comme remarque car perso je trouve la limite de plus en plus flou.
Quels sont selon toi les choses qui démarquent vraiment la limite ?

(OButterlin a déjà cité les applis très proche de la machine : manipulation d'apis système, jni etc...)


Ps : citrix je l'ai jamais testé avec farcry mais quand je vois des fermes citrix avec 32Go de ram (sic..) je me dis que finalement le plus survitaminé des deux n'est pas celui qu'on croit ^^

[OButterlin]

Mais justement, quand tu dis "on ne fait pas les mêmes choses dans une philosophie 'client léger' et 'client lourd'" ca m'intéresse comme remarque car perso je trouve la limite de plus en plus flou.
Quels sont selon toi les choses qui démarquent vraiment la limite ?

(OButterlin a déjà cité les applis très proche de la machine : manipulation d'apis système, jni etc...)

Il y a également la problématique "connexion". Il est certain que sur une machine non connectée, on aura du mal à faire du web (sauf à intégrer le serveur d'application à la machine, on est d'accord )

Sinon, l'accès aux ressources n'est même pas forcément une limite de la techno web, on pourrait passer par des applets signées, bon, pour le jni, ça risque de se compliquer...

[nouknouk]

Mais sur le fond, je suis d'accord avec toi, les 2 technos ne s'opposent pas, elles se complètent.

Tu l'a dit mieux que moi avec mon analogie pourrie

Il n'en demeure pas moins que swing est compliqué et n'a pas beaucoup évolué depuis qu'il existe...

Oui et non:

Pour le côté compliqué: une librairie pour faire une IHM 'client lourd' impose certaines contraintes spécifiques au client lourd. Je pense à l'exemple donné dans le billet à propos de l'EDT: n'importe quel framework d'IHM a besoin de pouvoir séparer la gestion de l'IHM d'un côté (EDT) et les traitements plus ou moins lourds du programme d'un autre côté. Et techniquement, on ne peut pas faire autrement si on ne veut pas 'freezer' l'interface dès qu'on fait un traitement lourd.

Qt par exemple propose exactement la même chose, à la différence près que le thread 'par défaut' (ie. celui où on exécute le code qu'on écrit sans penser 'thread') est celui de la gestion de l'IHM.

Pour la remarque à propos des layouts, je plussoie mais en modérant un peu les propos: le problème ne vient pas d'une mauvaise conception en soit. Le souci vient avant tout d'un framework qui reprend les standards ... d'il y a 10 ans.

Pour le côté évolution: c'est vrai que Sun a pendant trop longtemps abandonné Swing et c'est ça qui fait que Swing est un peu la mal aimée des librairies d'IHM pour client lourd. Sur ce point, on est totalement d'accord: là où certaines librairies se sont vues évoluer au cours des 10 dernières années (genre Qt), d'autres ont stagné par manque de moyens alloués au projet (résultant de considérations stratégiques de la part de Sun).

Il y a également la problématique "connexion". Il est certain que sur une machine non connectée, on aura du mal à faire du web (sauf à intégrer le serveur d'application à la machine, on est d'accord )

C'est une des différences fondamentales en effet ; quant au webstart et les applets, attention au contre sens: ça n'a jamais été du client léger, mais bel et bien du client lourd qui a simplement une technique de déploiement spécifique.

[...]on pourrait passer par des applets signée, bon, pour le jni, ça risque de se compliquer...

On sort du sujet initial, mais pour info, le JNI est parfaitement utilisable avec une applet (signée) ou du Webstart.
Les applets qui utilisent JOGL ou LWJGL - genre les jeux comme Bang!Howdy - en sont un excellent exemple pour utiliser la 3D hardware (openGL) via du JNI.
Typiquement, pour continuer à assurer le support multi-plateformes, on inclut les librairies pour chaque plateforme (genre win/linux/mac) directement dans le JAR.

[OButterlin]

Je dirais aussi que tout n'est pas pourri dans swing, le côté MVC natif me plait bien...
Avec swing, on peut tout faire... le problème, c'est qu'il y a beaucoup à faire... des fois même pour une valeur ajoutée proche de 0...

L'EDI fait beaucoup également, de ce côté, Eclipse a un métro de retard par rapport à NetBeans...

[robert_trudel]

c'est sûr que si on vient de vb, delphi... on peut trouver swing pas trop évident...

le concept des layouts est très puissant, après si on veut pas coder à la main, il y a les outils pour le faire...

GWT ne devrait pas être difficile à apprendre pour celui qui a déjà développé avec swing

[eclesia]

Je developpe surtout en swing les interfaces en ce qui me concerne, depuis 4ans environ.
C'est vrai qu'il faut comprendre et utiliser correctement l'EDT pour eviter les freeze mais c'est plus une question d'habitude qu'un veritable probleme.

C'est vrai que swing n'evolue pas enormement au sein de la JRE, mais en a t il vraiment besoin ? tout les composants sont parfaitement rodé et stable et il y a toute la base necessaire. on y ajoute swingx ou autre pour des bonus et on est bon.
Il n'y a rien a rajouter, qu'est ce qui pourrait evoluer encore ? l'API est deja mature en soi.

Quand a comparer Swing et J2EE, comme c'est dit plus haut, ce n'est pas comparable. pour avoir fait un peu de jsp et de jsf, je trouve ces facons de faire particulierement horrible, peu efficace et contraignante.

C'est aussi vrai que swing est complexe, mais c'est a double tranchant. c'est un peu plus dur a manipuler mais on peut faire plus de chose.

Swing me parait un bon compromis entre difficulté et possibilité. Je concois que ca rebute les débutants mais on ne peut pas lié les deux aussi facilement.

Devrait-on faire un client lourd en Java ?
Oui, et plutot deux fois qu'une.
Je privilégi toujours les applications JavaWebStart ou applet aux applications web pour ma part.

Vive Swing

[nicorama]

Je ne trouve pas le système de layout particulièrement compliqué. Ce n'est pas plus compliqué que d'utiliser les DIV imbriqués avec des float:left et clear:both.
Par contre, OK, le CSS permet d'obtenir un rendu différencié - et donc marketable - de façon bien plus rapide et efficace que les Look And Feel de conception antique.

La prochaine version (évolution) de Swing devrait en tenir compte.

[entreprise38]

Idem, Swing n'est certainement pas une techno à proposer à un débutant ou pire à quelqu'un qui n'est pas motivé, il n'en reste pas moins un outil diablement puissant et jouissif lorsqu'on (et seulement lorsqu'on) le maîtrise

Après, je comprends parfaitement que l'on puisse préférer la simplicité d'une interface HTML+CSS, mais bon ce sont tout de même deux choses différentes, car Swing ce n'est pas "que" de la présentation, c'est l'EDT, etc, c'est très lié au reste de l'appli. Le couple (x)HTML + CSS quant à lui, ce n'est "que" la partie présentation, donc forcément c'est beaucoup plus abordable pour n'importe qui.
Ce que je comparerais plutôt, ce serait Swing VS : HTML + CSS + une bonne application du modèle MVC en PHP/ASP, et là y'a pas photo, Java + Swing a gagné mon petit cœur de développeur.

[hugo123]

Je suis assez d'accord que Swing est assez puissant (la lecture de Filthy rich client est d'ailleurs pas mal pour ceux qui en doutent), simplement il me semble, peut être a tort, qu'il est plus simple par la suite de trouver des personnes capable de maintenir une appli J2EE qu'une appli Swing.
Perso je suis tombé sur une appli Swing à maintenir assez mal foutu, avec des tas de bugs graphiques car la rêgle de l'EDT n'était pas souvent respecté, des freeze et une absence de modèle de conception propre. Forcément ca aide pas à l'apprécier ^^

Après c'est peut être aussi une question d'outillage. Comme je le disais dans le post initial, en J2EE j'ai des frameworks pour structure mon développement. Si je les suis, je suis obligé d'appliquer un modèle de programmation relativement rigoureux. Si je prends comme exemple Struts, on peut le critiquer sur pas mal d'aspects (je ne suis pas le plus grand supporter de struts) mais il a le mérite d'être super structurant. Et c'est vrai pour la majorité des frameworks.
En fait coder du Swing parfois ca me rappelle le fait de coder des servlets directement sans aucun framework.
Quelqu'un connait un framework structurant pour Swing ? Le seul que j'ai vu c'est celui de Swing lab (https://appframework.dev.java.net/).

Toujours dans la catégorie outillage, je ne suis pas un designer né, par contre quand c'est du CSS je sais facilement trouver des exemples sur le net d'un truc approchant, je fais "afficher la source" et j'ai toute la partie présentation de l'appli qui m'apparait. En Swing l'équivalent c'est de copier le jar, le décompiler et j'ai aucune garantie de retrouver facilement la partie présentation uniquement ^^
Et puis j'ai des tas de sites pour m'aider a trouver l'effet qui tue, des éditeurs gratuits etc...
Rien qu'avec le plugin firefox "web developper", je peux très facilement voir en live mes modifs sans recompiler et modifier la partie présentation sans douleurs.
La partie skin de Swing c'est une autre paire de manche, c'est super puissant (pour preuve Substance qui l'exploite très bien) mais réservé à une autre catégorie de personne. Perso j'ai jamais réussi à faire mon propre skin ^^ Et j'ai pas trouvé d'outils pour cela, je suis d'ailleurs SUPER preneur d'un outils me permettant de créer ou retroucher un skin.

Et dernier point, les animations. Sur Swing j'ai vraiment du mal à dépasser l'aspect russo/polonais du Swing de base.
Faire du fade sur les éléments d'un tableau en rollover, de l'alternance de couleurs, une petite flêche sur le tableau en fonction de son ordre de tri, tout ca c'est trivial sur du Web. Ca l'est beaucoup moins sur Swing mais avec Jide et Substance il y a quand même de meilleures briques qu'avant.

Juste une petite remarque par rapport au commentaire :

C'est vrai que swing n'evolue pas enormement au sein de la JRE, mais en a t il vraiment besoin ? tout les composants sont parfaitement rodé et stable et il y a toute la base necessaire

Je ne retrouve pas l'article du fondateur de Jide mais celui ci avait fait un bon résumé des bugs connus de l'API non corrigé par Sun pour cause de compatibilité (le revers de la médaille de la compatibilité ascendante). Dommage que je ne le retrouve pas, mais du coup je suis tombé sur l'article suivant qui va un peu dans le même sens (http://www.softwarereality.com/soapbox/swing.jsp), notamment le paragraphe 8. L'API a des bugs que corrige justement des librairies additionnelles (dont Jide), c'est tout de même dommage.
Et puis aujourd'hui je trouve que Swing manque pas mal de nouveaux widgets : calendrier, dual list, combox avec filtre de recherche et autocomplétion, etc... des composants pour la plupart triviaux et bien implantés côté web. Rien que les layouts, je préfère largement utiliser le FormLayout de Jgoodies, ou le TableLayout et d'autres encore plutot que ceux de base. Mais pour tous sans exception je galère a mort sans éditeur approprié... Avec Swing designer ou Jform designer ok (mais c'est payant), par contre les faire à la main c'est vouloir se faire mal ^^ Je n'ai pas trouvé d'éditeur correct gratuit, Jigloo, Visual editor ou Matisse ne gère pas les layouts qui m'intéressent. Pareil, si vous connaissez je prends !!

Bon, je vais m'arrêter la. Je pense que vous aurez compris que ce qui me manque c'est l'outillage. Du coup si vous avez vos petits outils, vos frameworks etc... allez-y, partagez !

[jmini]

Peut-être que je n'ai pas tout compris en lisant ça :
E4, le futur de la plateforme Eclipse, prenez y part !

Mais la plateforme Eclipse (on ne parle pas de l'IDE là, le projet va plus loin), semble ouvrir la porte à ceux qui veulent développer de la génération de GUI (je ne connais pas le terme technique) façon HTML+CSS...

Il me semble que c'est le but de l'aspect Interfaces Déclaratives (XWT) qui fait partie du projet.

Après c'est certain qu'on repose sur SWT et plus sur SWING... Mais pour ceux qui cherchent des GUI rapidement créées (à la HTML...), ça peut visiblement être une solution.


Est-ce que je n'ai rien compris ?


.

[bouye]

Dans une moindre mesure, vouloir comparer JavaFX et Swing, c'est amha également un peu comme vouloir comparer Flash et Qt: il y en a un qui est pensé pour faire du multimédia, orienté "applets internet" et hautement graphique ; l'autre pour faire des IHM d'applications classique type 'client lourd'.

Ce qui n'a pas empecher les marketeux et les divers visages publiques cote Java/JavaFX de Sun de declarer que JavaFX c'etait un Swing 2.0 a sa sortie

[OButterlin]

Je rebondis sur ce qu'à dit eclesia, ce n'est pas une critique qui t'est adressée, mais plutôt un lieu commun qui m'interpelle...

Quand a comparer Swing et J2EE, comme c'est dit plus haut, ce n'est pas comparable. pour avoir fait un peu de jsp et de jsf, je trouve ces facons de faire particulierement horrible, peu efficace et contraignante.

Faudrait arrêter de comparer swing à j2ee... ça n'a rien à voir...
On utilise très souvent des briques j2ee dans les applications swing.
Swing s'oppose plutôt à une application web, la notion de client lourd ou client léger.

Devrait-on faire un client lourd en Java ?
Oui, et plutot deux fois qu'une.
Je privilégi toujours les applications JavaWebStart ou applet aux applications web pour ma part.

Plutôt 2x qu'une ? Je ne vois pas les choses comme ça...
Dans certains cas une application client lourd s'impose, dans d'autres, c'est l'application web.

Pour le client web, il faudra alors choisir le/les framework, dans une jungle de plus en plus vaste, définir le nombre de couches, choisir les api (j2ee), etc...

Si c'est le client lourd qui est retenu, les questions suivantes seront du genre, mon client doit s'adapter à tous les OS ou pas, mon client doit être super performant, etc...

Pour la portabilité, il n'y a pas photo.
Pour la performance des développements, pour ma part, un C++ Builder ou un Delphi sont largement mieux (mais alors, LARGEMENT )

Ce que je reproche à tous ces RAD, c'est le mélange de genre (au niveau sources). Sans EDI digne de ce nom, un chat n'y retrouve pas ses petits...
Contrairement aux framework web (struts par exemple, ou JSF) qui structurent de facto par couches.

Ensuite, il est vrai, on tend plutôt vers ce qu'on maîtrise le mieux...
Appréhender une application web est un peu plus compliqué qu'un client lourd, il faut plus de temps, même si chaque couche est globalement plus simple que swing.

[Aurelien.Regat-Barrel]

Pour le côté évolution: c'est vrai que Sun a pendant trop longtemps abandonné Swing et c'est ça qui fait que Swing est un peu la mal aimée des librairies d'IHM pour client lourd. Sur ce point, on est totalement d'accord: là où certaines librairies se sont vues évoluer au cours des 10 dernières années (genre Qt), d'autres ont stagné par manque de moyens alloués au projet (résultant de considérations stratégiques de la part de Sun).

Les créateurs de Qt ont sûrement compris cela puisque l'API de Qt 4 a été assez fortement Java-isé (d'un point de vue C++ en tous cas), chose qui est devenue plus compréhensible quand QtJambi est sorti il y a 3 ans déjà.
http://www.javaworld.com/javaworld/j...8-qtjambi.html

QtJambi permet d'utiliser Qt comme toolkit graphique Java. L'idée était séduisante, mais ça a fait un flop, et son développement est train d'être abandonné.

Personne n'a jamais essayé ?

[nouknouk]

Dans certains cas une application client lourd s'impose, dans d'autres, c'est l'application web.

Je plussoie. S'il n'y avait qu'une seule techno, une seul lib, un seul langage, une seule façon de coder, etc... qui était la meilleure en tout, ce débat n'aurait même jamais existé puisque tous les autres auraient disparus

Pour le reste et les critères, il y a beaucoup de choix, et les grandes 'boites' dans lesquelles on a l'habitude de classer certaines technos ne sont pas toujours complètement vraies, par exemple:

- par exemple, quand on parle portabilité, on pense tout de suite Java ; mais c'est un peu vite oublier que C++ avec un framework comme Qt par exemple est tout à fait capable de compiler sur Win, Mac & Linux sans toucher à la moindre ligne de code.

- concernant les performances d'exécution, on pense tout de suite à C ou C++ ; mais la différence entre les langages en code managé (Java, C#, ...) et les langages compilés (C/C++, ...) tend à se réduire de plus en plus. Et dans 90% des cas, ça ne fera aucune différence dans l'utilisation concrète.

- etc...

Mais comme OButterlin l'a évoqué, les technos c'est très loin d'être les seules considérations à prendre en compte ; amha, le plus important reste la connaissance et les expériences passées de l'équipe qui va faire le développement.

Et il vaut 100 fois mieux opter pour un développement en Java/Swing par une équipe qui a l'habitude de bosser sur ces technos, plutôt que par exemple vouloir imposer du C++/Qt parce que sur le papier, le C++ serait un peu plus adapté au projet en question.

En d'autres termes, tant que le choix de la techno n'est pas imposé par certaines contraintes techniques fortes et indépassables, il vaut souvent mieux privilégier non pas la techno la plus adaptée, mais celle que l'équipe en charge du projet connaît le mieux amha.

[pseudocode]

Pour ma part, le constat est simple...

Swing

• Avantages : orienté-objet, indépendant de la plateforme.
• Inconvénients : orienté-objet, indépendant de la plateforme

Ce sont des avantages car c'est totalement en accord avec la philosophie Java.

Ce sont des inconvénients car on décrit plutôt les IHM suivant un modèle "form/action" (mode déclaratif, evenementiel, ...) . Et on demande également de tirer avantage de toutes les possibilités des toolkits natives (windows, QT/GTK, ...).