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, ...).