Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Devrait-on faire un client lourd en Java ?
Propositions autour du positionnement de Sun Microsystems sur Swing

Le , par hugo123

42PARTAGES

0  0 
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

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de OButterlin
Modérateur https://www.developpez.com
Le 07/11/2009 à 18:52
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...)
0  0 
Avatar de bouye
Rédacteur/Modérateur https://www.developpez.com
Le 09/11/2009 à 1:34
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
0  0 
Avatar de nouknouk
Modérateur https://www.developpez.com
Le 09/11/2009 à 10:54
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.
0  0 
Avatar de OButterlin
Modérateur https://www.developpez.com
Le 09/11/2009 à 11:00
Citation Envoyé par nouknouk Voir le message

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...
0  0 
Avatar de hugo123
Rédacteur https://www.developpez.com
Le 09/11/2009 à 11:12
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 ^^
0  0 
Avatar de OButterlin
Modérateur https://www.developpez.com
Le 09/11/2009 à 11:24
Citation Envoyé par hugo123 Voir le message

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...
0  0 
Avatar de nouknouk
Modérateur https://www.developpez.com
Le 09/11/2009 à 11:54
Citation Envoyé par OButterlin Voir le message
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).

Citation Envoyé par OButterlin Voir le message
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.
0  0 
Avatar de OButterlin
Modérateur https://www.developpez.com
Le 09/11/2009 à 12:00
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...
0  0 
Avatar de robert_trudel
Membre éclairé https://www.developpez.com
Le 09/11/2009 à 18:33
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
0  0 
Avatar de eclesia
Rédacteur https://www.developpez.com
Le 09/11/2009 à 18:53
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
0  0