Discussion :

[dfiad77pro]

"Je ne peux pas laisser dire que java est lent..."

Ah ah, elle est bien bonne celle là !

Va pourtant bien falloir le laisser dire, car les machines virtuelles java sont d'une lenteur affligeante.
Si c'est à cause de mauvais algos, il faut croire que tous les mauvais développeurs sont sur java...
A chaque fois que je lance une application java, j'ai l'impression de faire un bon de 15 ans en arrière.

Pourtant des applications comme VUZE se lancent assez rapidement .

En java ce qui est très lent c'est surtout la partie graphique ( swing et compagnie) .
SWT à beau être rapide mais c'est pas très agréable à coder.

[Mickael_Istria]

"Je ne peux pas laisser dire que java est lent..."

Ah ah, elle est bien bonne celle là !

Va pourtant bien falloir le laisser dire, car les machines virtuelles java sont d'une lenteur affligeante.
Si c'est à cause de mauvais algos, il faut croire que tous les mauvais développeurs sont sur java...
A chaque fois que je lance une application java, j'ai l'impression de faire un bon de 15 ans en arrière.

Tu as des preuves de ce que tu racontes? Et lent compare a quoi? Parce qu'en cherchant "performance C++ versus Java" dans Google, il y a vraiment un paquet de resources qui ont tendance a te donner tort. Se seraient-ils tous trompes?

[OButterlin]

"Je ne peux pas laisser dire que java est lent..."

Ah ah, elle est bien bonne celle là !

Va pourtant bien falloir le laisser dire, car les machines virtuelles java sont d'une lenteur affligeante.
Si c'est à cause de mauvais algos, il faut croire que tous les mauvais développeurs sont sur java...
A chaque fois que je lance une application java, j'ai l'impression de faire un bon de 15 ans en arrière.

Et pourtant... même Swing n'est pas lent quand c'est bien codé...

Maintenant, un programme qui stocke en mémoire de grosses quantités de données sera peut-être limité, surtout en 32bits... de là à dire qu'il y a un problème d'architecture... OUI !
Pour avoir développé sur bien des outils et depuis bien longtemps, je ne pense pas que java soit plus lent qu'autre chose.
On peut (souvent) dégager une chose par contre : plus le développement est facilité par un outil (RAD ou framework), plus on trouve de grosses daubes

[plawyx]

"Je ne peux pas laisser dire que java est lent..."

Ah ah, elle est bien bonne celle là !

Va pourtant bien falloir le laisser dire, car les machines virtuelles java sont d'une lenteur affligeante.

J'ai une petite question à ce sujet:

Java étant lent, Pourquoi est-il aussi (en %) utilisé dans le trading haute fréquence par exemple?

De plus, une jvm est fournie avec des réglages médians. Normal compte tenu de la diversité des applications. Mais en cas de besoin, une jvm peut être tuner et fournir à ce moment là des performances assez étonnantes pour un langage "lent".

[professeur shadoko]

Java étant lent, Pourquoi est-il aussi (en %) utilisé dans le trading haute fréquence par exemple?

ou dans le calcul scientifique intensif (CERN par ex.)

[plawyx]

ou dans le calcul scientifique intensif (CERN par ex.)

C'est pour ça que je ne comprends pas cette réputation de lenteur qui lui colle à la peau.

[sekaijin]

Bonjour.

J'utilise Java dans un contexte un peu particulier probablement.

Pas de traitement lourd (algos simples courts, de petits objets)
Pas d'iHM

Mais de très très nombreux objets.
je travaille dans le monde hospitalier
Ce sont 5 millions de consultations externes.
1,2 million de séjours
1,1 million d'urgences
Bref vous aurez compris qu'il y a beaucoup de choses qui passent par nos les outils.

Et je dois dire qu’indéniablement la qualité du développement change la donne.
Nous avions une solution déployée partiellement (40 établissements pour la gestion logistique et comptable. Un seul, pour la gestion de l'activité médicale).
Pour la gestion logistique nous avons été obligés de dédier une machine virtuelle pour la gestion des livraisons. De nombreuses lenteurs, beaucoup d'indisponibilité du système.

Vous m'auriez demandé à cette époque si Java était lent, je pense que je n'aurais pas eu la même réponse qu'aujourd'hui.
Bref, nous avons tout revu. Nous avons changé de solution. Mais nous sommes restés à Java. Et, aujourd'hui l'ensemble fonctionne sur 4 coeurs pa-risc. Malgré l'énorme volumétrie traitée par notre système, la latence du système se mesure en secondes. Lorsqu’aujourd'hui on constate une latence de 10s, tout le monde s'alerte. Les points faibles de la solution sont les entrées/sortie. L’usage du processeur et quasi négligeable.
Je suis toujours impressionné par la réactivité du système. Nous avons des dizaines de milliers de threads. Plutôt que des algos longs et complexes, nous avons opté pour des traitements courts, simples, et nombreux, qui communiquent entre eux de façon asynchrone. Le système reste pourtant très vif.

Si je faisais une comparaison, je dirais que nous sommes passés d'un camion des années 60 sur une route de haute montagne à un TGV. Pourtant nous n'avons pas changé de machine physique, nous avons diminué notre impact mémoire, nous avons supprimé des moteurs, nous n'avons pas changé de JVM.

Alors je ne sais pas si Java est lent ou rapide. Je ne sais pas si on peut affirmer que cette assertion est due à de mauvais développements. Mais mon expérience m'a montré que de mauvaises solutions peuvent avoir des résultats plus que catastrophiques. Après une longue carrière, je m'attendais à un gain de perf, mais je n'avais pas imaginé de telles proportions.

Pour ce qui est de l'évolution de Java je pense qu'il y a effectivement un gros héritage du modèle objet des années 1990.
Pour moi, Java souffrait d'un manque de clarté. Java c'est la JVM, le langage, et la Lib standard. Et pendant trop longtemps, on a considéré tout cela de façon monolithique.

Au fil du temps et en fonction des modes, on a vu la Lib Java gonfler comme un zeppelin. Le langage n'a quasiment pas changé. Et la JVM n'a subi que des améliorations techniques. Certaines très importantes.

Je pense que Java a pris un tournant il y a quelque temps.

La JVM est devenue un environnement d'exécution qui s'affranchit du langage. Pour la première fois depuis la version 1 une nouvelle instruction est apparue. Imaginez le processeur X86 13 ans sans aucune nouveauté.

Le langage en lui-même connait lui aussi une révolution en intégrant des technos des années 70 (lambda) et quelques éléments plus récents.

La Lib, elle a un gros travail et c'est toujours là que le bât blesse. Elle est devenue incohérente, lourde et redondante. Il y a bien eu une volonté de tout réorganiser. Mais nombre d'acteurs ne sont pas prêts à une rupture. Pourtant je pense qu'elle est inévitable.

Personnellement, j'aimerais voir arriver quelques changements. En premier lieu, supprimer définitivement les types primitifs qui ne servent à rien (char, int, long, bool et array). Java serait enfin tout objet.
Je supprimerais bien toutes les java IO historiques pour ne garder que des objets en nombre réduit.
Je verrais bien Java épuré des centaines de collections, en tout genre. Il y en a tellement que la plupart des développeurs n'en connaissent que 10% et utilisent toujours les 2 ou 3 même.
Je verrais bien une notion de profil comme cela avait été envisagé. Définissant des groupes de capacités permettant de n'avoir plus qu'un seul Java et non plus les JME et autre bidules.

J'aimerais une API permettant de savoir ce dont est capable la JVM. Plutôt que de jouer avec les classes présentes dans le ClassLoader. Couplé avec la notion de profil, pouvoir demander à sa JVM si elle gère l'affichage, le réseau, les ejb, etc. on trouve ça dans les environnements d'exécution normalisés proposant de la modularité.

Bref je pense qu'il a beaucoup à faire.
A+JYT

[adiGuba]

C'est pour ça que je ne comprends pas cette réputation de lenteur qui lui colle à la peau.

Les idées reçues ont la vie dure... tout simplement.

La réputation vient de plusieurs éléments :

• Dans les premières versions de Java, le bytecode était interprété ce qui ne donnait effectivement pas de grosses performances.
  Toutefois ce n'est plus le cas depuis 1998 et Java 1.2... mais l'idée de base reste présente dans les esprits.
  
  
• J'ai vu trainer sur le web des "astuces" pour optimiser le code Java qui datait de cette époque... mais qui n'avait plus lieu d'être !
  Elles ont pourtant perdurer pendant longtemps en continuant l'idée de "Java c'est lent" donc il faut optimiser à tout prix...
  
  
• Certains mécanismes sont très différents du C/C++, et en voulant comparer ou porter des codes C/C++, ou même en voulant "optimiser" son code car "Java c'est lent" on peut être amener à faire involontairement des choses incorrects en Java qui peuvent s'avérer catastrophique en terme de performances.
  
  L'inverse est aussi vrai : on peut faire quelque chose de catastrophique en C/C++.
  
  Toutefois ces derniers ne souffraient pas de cette image, et en cas de mauvaise perfs on remettait en cause l'algo et le code plutôt que le langage.
  Avec Java c'était plus facile de reporter le problème sur le langage ou la plateforme...
  
  
• AWT/Swing et les applets ont sûrement aussi fait beaucoup pour cela.
  Non pas que la techno soit mauvaise, mais plutôt car elle nécessite certaines connaissances (comme la gestion de l'EDT).
  Toutefois ces concepts n'était pas forcément bien documenter ou mis en avant, ni forcément simple à appréhender !
  Du coup on pouvait voir des programmes qui effectuaient toutes sorte de tâche dans l'EDT, ce qui a pour résultat de geler l'interface graphique et donc une grosse impression de "lourdeur".
  
  Mais c'est la méconnaissance du fonctionnement de ces technos qui entrainait cela...
  
  C'est aussi un peu la faute de Sun : l'API manquait de solution "simple" pour gérer cela.
  Par exemple si Swing est arrivé en standard dès 1998 avec Java 1.2, il faudra attendre 2006 et Java 6 pour que la classe SwingWorker soit intégré dans l'API.
  Avant cela il fallait la rechercher au fin fond d'un tutoriel pour la copier/coller... et il me semble même qu'il y avait plusieurs versions différentes plus ou moins complète...
  
  Encore maintenant il s'agit de notion pas forcément bien mis en avant...

a++

[Invité]

WRITE ONCE, HACK EVERYWHERE

ou dans le calcul scientifique intensif (CERN par ex.)

Des exemples ? Parce que en dehors de C ou FORTRAN, ça doit rester minoritaire ? On apprend ici que Java est très apprécié pour des calculs intensifs :
http://acs.lbl.gov/software/colt/
Mais est-ce justifié, à moins de développer sur une plate-forme et de faire tourner sur une toute autre plate-forme ?

Globalement, un langage qui a autant de classes et de méthodes ne peut pas être simple à aborder, et donc manque d'efficacité : quand on passe plus de temps à apprendre le langage qu'à l'utiliser, c'est qu'il y a un problème.
Personne n'a parlé d'outils comme PMD ou CheckStyle, ou d'autres : pourquoi ? Ils sont pourtant très révélateurs de certaines mauvaises manière de programmer...

[adiGuba]

WRITE ONCE, HACK EVERYWHERE

AND TROLL CONSTANTLY

Des exemples ? Parce que en dehors de C ou FORTRAN, ça doit rester minoritaire ? On apprend ici que Java est très apprécié pour des calculs intensifs :
http://acs.lbl.gov/software/colt/
Mais est-ce justifié, à moins de développer sur une plate-forme et de faire tourner sur une toute autre plate-forme ?

La portabilité est loin d'être le seul avantage de Java.
Java est nettement plus utilisé coté serveur, et son aspect portable n'y est d'aucune utilité...

C'est certe plus pratique si l'on doit changer d'environnement, mais cela reste possible également avec d'autres langages...

Globalement, un langage qui a autant de classes et de méthodes ne peut pas être simple à aborder, et donc manque d'efficacité : quand on passe plus de temps à apprendre le langage qu'à l'utiliser, c'est qu'il y a un problème.

Attention à ne pas mélanger le langage et les API.

La principale différence avec les autres langages c'est que Java intègre en standard une API très riche, là où il faudra forcément se tourner vers des librairies tierces avec d'autres langages.

Avec d'autres langages tu vas aussi devoir utiliser des librairies...

Personne n'a parlé d'outils comme PMD ou CheckStyle, ou d'autres : pourquoi ? Ils sont pourtant très révélateurs de certaines mauvaises manière de programmer...

Les mauvaises manières de programmer ne sont pas spécifique à Java. On peut faire autant de connerie en C... voir même plus !
Et ce n'est pas parce qu'il y a des outils de vérification du code que le langage est mauvais... juste que l'environnement de dev est plus sûr.





Des avantages de Java, de mon point de vue :

• Un langage simple et efficace. Certe verbeux mais très précis et facile à relire (ce qui est très important IMHO).
• Un langage relativement simple en comparaison d'autre langage (C++ par exemple), et qui limite les fonctionnalités "troublantes".
• Un langage compilé, avec un typeage fort, et donc assez "sûr".
• Un code facile à documenter, qui générè une documentation compréhensible par la majorité des dev Java.
• Une API standard énorme, et un écosystème de librairies encore plus grand.
• Un communauté tout aussi grande. Il est facile de se documenter ou de trouver de l'aide.
• Et bien sûr des performances réelles. A ce propos sur certains points un compilateur JIT peut effectuer des optimisations bien plus poussé qu'un compilateur classique (parce qu'il connait l'état du programme)

a++

[sekaijin]

Bonjour,

la portabilité à un avantage là où on ne l'attends pas.

ma MOA a des exigences très strictes. l'une d'elle est que les livrables ne soit pas modifiés durant le passage de la phase DEV à la PROD.
nous avons les étapes suivantes
DEV => ASSEMBLY => QUALIF => INTEG TECH => RECETTE => PRE PROD => PROD.
Le dev pour des raison de coût se fait sur des PC xp (32 bits)
chaque developpeur à son environnement en local.
Il peut à la demande déployer sur la plateforme ASSEMBLY ou il peux alors tester que son DEV s'assemble bien avec les composants des voisins.
Déjà ces deux espaces ont un changement majeur 32/64 bits pour la JVM

Lorsque le DEV est passé l'intégration continue produit un version RC la QUALIF vérifie quelle est conforme
LORSQUE cela est le cas on produit une Release.

à partir de là la MOA est stricte il est interdit de modifier 1 bit du livrable.
Elle passe à l'INTEG TECH qui à pour but que techniquement le livrable s'intégrera à l'environnement cible.
ensuite vient la Recette qui fait que des test fonctionnel et la preprod puis la prod.

là encore pour des raisons de coût les environnements ne sont pas tous identiques.

si nous étions en C++ ou en C le passage d'une plateforme à l'autre impliquerait une recompilation (Pa-Risc, X86, IA64, arm etc...). ma MOA refuserait alors le produit. où alors il faudrait que toute les plateformes soit à l'identique de la cible finale. si vous avez lu mes messages vous aurez comprit que ce coût serait exorbitant.

Donc finalement le fait que Java offre une portabilité est un gain non pas parce que l'application est destiné à être utilisée sur des machines différentes mais pour réduire les coûts.

Dans les SI la portabilité de Java est très appréciée là encore non pas parce que les applis doivent être utilisé sur des environnement hétérogène, mais parce que c'est une contrainte de moins à long terme.

Maintenir une machine capable de faire tourner une application développé en Cobol en 1968 est une contrainte très forte. savoir que l'application qu'on déploie aujourd'hui et qui à des chance d'être encore là dans 20ans ne bloquera pas l'évolution de l'infrastructure est pas un simple plus c'est un énorme gain de coût.

Cela à des limites bien sur mais la portabilité de Java réduit ces contraintes donc les coût.

A+JYT

[Peck777]

Je suis assez récent en Java (2 ans) et venant de C++ et Delphi, c'est sûr, ce n'est pas le même voyage. Mais je m'y suis fais et j'avoue que je pourrais revenir en arrière facilement.

Mon expérience des IDE Eclipse et Netbeans (je vote Netbeans) Eclipse et le système de plug-ins c'est vraiment lourdingue !! même sur une station de travail, c'est horrible.
Bon Ok tout n'est pas noir dans Eclipse mais depuis 5 mois que je suis sous Netbeans, je revis ^^

Globalement, il me semble que tous les projets ne comparent pas. Pour ne citer que les 2 cas les plus courant: IHM Web et IHM riche. j'écarte volontairement les couches serveurs car les performances sont tout à fait comparables aux autres framework. ;
en Web, t'as pas 10 solutions, soit tu codes jsp/struts ou tu choisi un framework intermédiaire (comme Wicket) qui allie parfaitement HTML5 en FrontEnd et Java en BackEnd.
évidemment ça n'a plus rien à voir ^^
Pour les clients riches, c'est plus compliqué, mais globalement identique. Il ya les dinosaures et les touchy !
J'ai exploré SWT et Eclipse RCP. Pas encore JaxaFX. Mais entre les 2 premiers, je vote SWT !!! Mon dieu que le RCP c'est lourd.
Et je sais plus qui dans ce thread a dit que SWT est ne devrait plus être utilisé. Vu ce qu'on est capable de faire en SWT + SwingX + 2-3 lib sympa, je vois pas ce qu'on peux faire de mieux...
Si javaFX me fait des camembert 3D et des transitions de TabPanel en slide à la jQuery, euuhhhh j'en pas besoin, à moins que mon client m'en fasse expressément la demande mais j'en doute...

et pour l'utilisation de Maven et toute sa clique, je vote Oui !! Vive Maven ^^ Et franchement, je préfère 100 fois la compil sous maven que le build d'Eclipse que-tu-sais-même-pas-ce-qu'il-est-train-de-faire !
alors bien sûr un projet Maven, ça se travaille, ça se paramètre, ça se bichonne. Eh les mecs ! non seulement vous savez exactement ce qu'il fait (car vous lui dites quoi faire) et si vous trouver
lent, ben acheter un nouveau pc ou revoyez votre code ^^

Allez, codez bien...

[Gugelhupf]

supprimer définitivement les types primitifs qui ne servent à rien (char, int, long, bool et array). Java serait enfin tout objet.
Je supprimerais bien toutes les java IO historiques pour ne garder que des objets en nombre réduit.
Je verrais bien Java épuré des centaines de collections, en tout genre. Il y en a tellement que la plupart des développeurs n'en connaissent que 10% et utilisent toujours les 2 ou 3 même.

Je viens de regarder le package function du jdk8 car je me suis intéressé à l'interface Function... quand j'ai vu cette interface au début je me suis dis qu'elle n'était pas forcément très utile (avec un seul paramètre... surtout que les variadic n'existent pas comme en C++11)... par contre quand j'ai vu les autres interfaces comme IntFunction et LongFunction je me suis dit mais qu'est-ce qu'ils ont fumés ? Ça sert à rien
Donc ça risque même d'empirer à l'avenir je pense.

en Web, t'as pas 10 solutions, soit tu codes jsp/struts ou tu choisi un framework intermédiaire (comme Wicket)

Les framework Web sont nombreux en Java (pas autant qu'en PHP mais tout de même). Si on se limite à struts on est pas sorti de l'auberge.
Tu as JSF2, Spring etc...

[sekaijin]

Oui comme tu dis on n'est pas sorti de l'auberge.

franchement je ne vois pas pourquoi le compilateur Java ne saurait pas crée un objet Long dans une expression comme

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Long myLong = 0L;

C'est pas la mer à boire.

pour moi la seule différence entre long et Long c'est que lorsque on le passe en paramètre à une fonction le premier est passé par valeur, le second par référence. là encore ce n'est pas la mer à boire que d'optimiser le compilateur pour qu'il fasse au mieux en fonction du contenu de la méthode.

quant au dev Web il n'y a pas 10 solution il y en a environ 500. c'est justement un des reproches fait à Java.
trops de solutions tuent les solutions.
A+JYT

[_skip]

pour moi la seule différence entre long et Long c'est que lorsque on le passe en paramètre à une fonction le premier est passé par valeur, le second par référence. là encore ce n'est pas la mer à boire que d'optimiser le compilateur pour qu'il fasse au mieux en fonction du contenu de la méthode.

De plus on s'en fout de comment il passe puisque Long est immutable (pour notre plus grand bien à tous). La grosse différence c'est la mémoire et les problèmes de boxing/unboxing. C'est d'ailleurs un enjeu d'optimisation pour les langages de la JVM tels que ceylon de déterminer si les types primitifs peuvent faire l'affaire ou si leurs homologues classes doivent être utilisés. Et malheureusement avec les génériques en carton-pâte de java, dès que des collections sont en jeu, ce sera la 2e solution.

[thelvin]

Je verrais bien Java épuré des centaines de collections, en tout genre. Il y en a tellement que la plupart des développeurs n'en connaissent que 10% et utilisent toujours les 2 ou 3 même.

J'épurerais les obsolètes Vector et Hashtable, mais en dehors de ça je vois pas. Si on ne se sert que de 2 ou 3 collections c'est parce que d'habitude on n'a pas besoin des autres, parce que le monde comporte peu de problèmes qui les font intervenir en dehors de bibliothèques qui s'en occupent déjà. Mais lorsqu'on en a vraiment besoin, on fait quoi si elles sont pas là ?

Je vois pas en quoi il ça peut gêner de fournir une liste complète de structures de collections vues en algorithmique, avec les intérêts et inconvénients de chacune, bien nommées, bien placées. Et on les trouve quand on se rappelle la fois où on regardait les "implémentations connues de Collection, List, Map."

[sekaijin]

Je n'ai pas dit que je voulais tout supprimer pour en garder 2. Je dis qu'il y beaucoup de redondance dans ce domaine dans java et que remettre les choses à plat serait bien venu.

Je trouve déplorable qu'un certain nombre d'acteur de java proposent des librairies pour réimplémenter où encapsuler les collections pour en fournir un access plus simple et surtout plus cohérent.
Pour moi cela montre bien que de bas il y a un malaise.

Je constate que depuis des années Java ajoute de couches (et pas que pour les collections) sans se soucier de la cohérence du tout.

Cela rejoint pour moi la notion de plateforme modulable à la demande.
Un démarrage de java avec java -profile=1.6 suffirait à permettre de repenser proprement cet empilage sans avoir à ce soucier d'une compatibilité ascendante de 30 ans.

L'utilisateur ayant le choix de continuer à utiliser les anciennes API ou les versions rénovées.

A+JYT

[Mickael_Istria]

Mon expérience des IDE Eclipse et Netbeans (je vote Netbeans) Eclipse et le système de plug-ins c'est vraiment lourdingue !! même sur une station de travail, c'est horrible.

NetBeans a quasi-exactement le meme systeme de plugins, mais comme il y en a beaucoup moins et qu'ils sont developpes de maniere homogene (globalement plus par une equipe qu'une communaute), ca n'est pas (encore) un probleme.

J'ai exploré SWT et Eclipse RCP. .... Mais entre les 2 premiers, je vote SWT !!! Mon dieu que le RCP c'est lourd.

Il ne sont pas incompatibles, ni meme concurrents. Bien au contraire! SWT est une API graphique pour creer des UI. C'est comparable a Swing, GTK, Qt ou JavaFx. Eclipse RCP c'est un mode d'application, bases sur des concepts d'extensions et de modules, mais dont la partie juste UI est faite en SWT.

Si javaFX me fait des camembert 3D et des transitions de TabPanel en slide à la jQuery, euuhhhh j'en pas besoin, à moins que mon client m'en fasse expressément la demande mais j'en doute...

J'ai la meme impression. Les clients riches sont generalement preferes pour les workstations ou on privilegie la productivite. Tous ces eye-candies, transitions et compagnie sont a mon avis plutot hors-sujet, et ne correspondent pas vraiment aux besoins et aux envies des clients riches.

Et franchement, je préfère 100 fois la compil sous maven que le build d'Eclipse que-tu-sais-même-pas-ce-qu'il-est-train-de-faire

Si tu installes les plugins Maven d'Eclipse, alors le comportement dans l'IDE devient plus proche du comportement "standard" de Maven et ca evite pas mal de petit souci de choses qui marchent dans un contexte et pas dans l'autre.

[OButterlin]

Il ne sont pas incompatibles, ni meme concurrents. Bien au contraire! SWT est une API graphique pour creer des UI. C'est comparable a Swing, GTK, Qt ou JavaFx. Eclipse RCP c'est un mode d'application, bases sur des concepts d'extensions et de modules, mais dont la partie juste UI est faite en SWT.

SWT me surprend toujours un peu, on perd l'essence même de java et de sa portabilité avec la couche native spécifique à chaque OS.
J'ai essayé JavaFX à sa sortie, mais ça ne m'a pas emballé.
Pour RCP, je ne peux rien dire, je ne connais pas.
En client lourd, Swing reste mon préféré, malgré sa courbe d'apprentissage plutôt conséquente... on peut tout faire

Il faut dire que chez nous, on fait surtout du web, et là, java et tous les framework/libraries existants sont vraiment top, mais il faut bien choisir en fonction de ce qu'on fait.
Pour une application avec forte charge, JSF/Primefaces sont lents, les vieux struts/struts-layout bien plus rapides mais beaucoup moins riches... bref, ils ont tous des caractéristiques bien définies.
Ce que je trouverais vraiment bien, c'est d'avoir une liste des différentes solutions avec leurs + et - (mais ça n'a rien à voir avec java)

[Mickael_Istria]

SWT me surprend toujours un peu, on perd l'essence même de java et de sa portabilité avec la couche native spécifique à chaque OS.

Un peu comme la JVM en fait L'implem de la VM est differente selon les OS, c'est pareil pour SWT. Ca ne le rend pas moins portable.