Discussion :

[Clement Cunin]

une petite appli avec une fenetre et 3 boutons, il faudrait que ça soit plus simple.

c'est jamais que 10 lignes de code.

avec Swing : les bugs. Il y en a beaucoup (trop !).

Je n'ai jamais eut de problème de se coté la... je dis pas qu'il n'y a pas de petit bug, mais il claire qu'il n'y en a pas une multitude comme tu voudrait le faire croire ...

parfois ça me parait surréalistement lent

Si c'est surréalistement lent, c'est probablement qu'il y a une erreur de conception de votre coté...
J'ai deja fais de nombreuse interface graphique complexe, et j'ai jamais eut de problème de lenteur.

Un des problèmes de Java, c'est qu'il parait trop simple au yeux des nouveaux programmeurs, don beaucoup se lance dans le developpement d'application sans comprendre les principe de base de l'api... le resultat est souvent catastrophique !

[thecat]

Dire que les problèmes de lenteurs viennent d'une mauvaise programation est complètement faux. La moindre petite interface en Swing n'a pas une réactivité satisfaisante sur une becane "normale", c'est à dire pas le dernier pentium à la mode.

Ensuite pour les bugs, je sais qu'avec la version 1.3 je n'avais pas les même sous Win que sous Linux, donc en additionnant ca en faisait un paquet oui.

Cela dit je trouve l'API Swing trés biens ... mais lente.

[Traroth]

Sans vouloir polemiquer, je ne dis pas que le nombre de bugs est si elevé que ça. Il est simplement trop elevé pour une API destinée au professionels. Creer une application en entreprise est une affaire serieuse. On n'a pas le temps de contourner les bugs de l'API.
Pour la vitesse, j'admets ne pas avoir suffisament testé la version 1.4 pour pouvoir en parler, mais la version 1.3 etait effroyable, sur un portable avec un PIII à 850 MHz, 256 Mo de RAM et W98.

[Traroth]

Tout ça pour dire que Swing a principe plus que sympa, mais donne etrangement l'impression d'etre negligé par Sun, comme s'ils avaient renoncé à s'implanter sur le poste client. Il est clair que ça n'est pas (plus) là qu'ils investissent en priorité

[Clement Cunin]

Il est simplement trop elevé pour une API destinée au professionels

Un certain nombre de grosse appli professionnel s'en sorte très bien: JBuilder ou SunOneStudio par example

Sans vouloir polemiquer, je ne dis pas que le nombre de bugs est si elevé que ça.

mais donne etrangement l'impression d'etre negligé par Sun

Pourrais-tu nous donner qq example de code qui ne fonctionne pas ?
Critiquer une api comme tu le fais n'a aucun sens !


Je vous rappel que le debat initiale etait Java vs c#

[Traroth]

Si tu regardes dans mes vieux messages (genre il y a un an), tu trouveras des exemples de phenomenes inexpliqués, à base de JDesktopPane, JScrollPane et JInternalFrame. Il y a une configuration (trop d'utilisateurs sur developpez.com pour faire une recherche moi meme, et ça fait un peu longtemps, je ne me rappelle plus trop) où ça ne marche pas du tout.
Et si tu cherches à pouvoir deplacer à la souris des elements Swing, style JCheckBox ou JRadioButton sur un meme panneau, je te souhaite bien du courage !
Maintenant, on n'a pas de problème avec les trucs les plus simples, ça tourne

Ne comprends pas mal ce que je dis. J'aime beaucoup Java, suffisament pour en faire tout les jours, mais Swing... Ca a quand meme de sacrés defauts.

Quant aux applis style JBuilder, je me suis laissé dire que leurs bibliothèques graphiques ont été largement customisées. Je ne sais pas si c'est vrai, mais je peux le comprendre...

[neo.51]

Pour essayer de revenir sur le Débat Java VS C#, je voudrais vous poser une question : vaut-il mieux avoir un programme avec une interface graphique plus rapide et pas portable(GDI+ de .NET) ou une interface graphique plus lentes et entièrement portable (swing)?

Tous mes clients sont sous windows, quel serait l'interet pour moi de faire du java plutot que du C# ? Une portabilité qui ne me sert pas mais que je paye par une interface graphique apparement plus lente

Ou peut-être existe-t-il d'autres interfaces graphiques en java ?

[Clement Cunin]

Et si tu cherches à pouvoir deplacer à la souris des elements Swing, style JCheckBox ou JRadioButton sur un meme panneau, je te souhaite bien du courage !

Si tu parle de déplacer des composants à la souris dans un container... Je l'ai deja fais ( 2x de maniere differentes ) Je peux te garantir que ca marche très bien !


Pour néo, c'est sûr que si tu ne veux pas que tes applications soit portable, alors c# ne pose pas de problème...
De plus, les interface Swing ne sont pas aussi lente que Traroth et thecat voudraient le faire croire... Les programme que j'utilise le plus (Eclipse et Jext) sont ecrit en Java et marche parfaitement bien !

[Traroth]

Il existe au moins une autre interface graphique : SWT, d'IBM. J'avoue ne pas savoir ce que ça vaut. Il parait que c'est bien (l'IHM d'Eclipse est faite avec).

Tu reponds toi meme à ta question : pourquoi faire une interface graphique portable si tu n'as pas besoin qu'elle le soit, alors que par ailleurs cette portabilité entraine d'autres defauts ?

[neo.51]

Donc portabilité =! performances (sur l'interface graphique)

J'ai encore d'autres questions :

Existe t'il des interface graphiques java qui ne sont pas portables ?

Sous windows au niveau performance avec le GDI+ de .NET ?


Lorsque'on parle d'interface graphique, on parle surtout d'applications qui tournent sur des postes client. Hors en moyenne dans les entreprises, combien de postes client Linux ? Windows ?

[thecat]

La lenteur de Swing viens surtout du fait que l'interface serra IDENTIQUE sur toutes les architecture, ce qui est biens plus que de la simple protabilité!
Il aurrait était interressant que Sun soit moins radical sur cela ... (que le checkbox soit rond, carré ou autre je m'en fout un peu, surtout entre différent poste client!)

pour Clement Cunin: quand une IHM n'est pas fluide sur un P2 500 396Mo, je suis désolé mais c'est que L'API est lente, et ce n'est pas moi qui chipote D'accord cette conf est "ancienne" mais il ne faut pas rigoler quand même, une IHM reste une IHM et ce n'est pas ca qui doit bouffer le CPU ...

Pour revenir un peu plus dans le sujet, je pense que perdre la portabilité est lourde de conséquence ... pour l'avenir. Si tu dévelope un soft spécifique pour une entreprise et puis basta d'accord, mais si tu commence à faire un aplication que tu va faire evoluer et distribuer à plusieurs futur client, là tu a plutot interet à conserver un maximum de portabilité.

Enfin il y à aussi le coup financier (trés criticable je l'avoue mais ...): j'ai bossé pour une boite qui faisait des soft en java pour les Tele-Operateurs et un argument c'était qu'il sufisait de récuperrer un bête PC, vous intalliez Linux+Java (gratuit) + notre-soft (payant) et vous mettez un TO derriere tous ca est c'est tout! -> l'extension était facile et économique. (mais la on rentre dans un autre débat ...)

Enfin pour recadrer vraiment le débat, et pour repeter les argument que j'avais donné un peu plus haut ... Le C# est un mauvais langage objet. Java est un meilleur langage objet (mais pas ideal avons le). Donc il ne faut pas promouvoir C# car si on doit utiliser tous les nouveaux langages alors qu'ils n'apporte rien de neuf, on ne sent sortira pas. A la rigeur, quitte à utiliser la plateforme .Net, il vaudrais mieux faire de l'Eiffel# qui lui est un langage objet qui apporte vraiment quelque chose de plus.

[neo.51]

Peux-tu développer sur le fait que : "C# est un mauvais langage objet" ?

[Clement Cunin]

Donc portabilité =! performances (sur l'interface graphique)

biensur que la portabilité est plus ou moins penalisante... mais java est aussi bien independant de l'os que de l'architecture. On passe de windows+intel a Solaris+Sparc en faisant une simple copie de fichier... Essaye de faire ca auvec un autre langage !

quand une IHM n'est pas fluide sur un P2 500 396Mo

Ca c'est pas uniquement java qui arrive a faire ca ... essaye d'installer XP sur cette machine et la jolie interface graphique pourtant codé en C++, compiler en native, et tout et tout ne fera pas pire qu'un interface Swing... D'ailleur chapeau bas au gus qui a programmer le nouveau cadre de selection de windows XP, celui avec l'effet de transparence surper jolie... qui ramme meme sur un Athlon 1Gh, 500 Mo de Ram...

Existe t'il des interface graphiques java qui ne sont pas portables ?

Celui qui proposerai ca se ferait tout simplement jeter dehors... ca n'a aucun interet. SWT permet une interface graphique native portable...

Combien de postes client Linux ? Windows ?

A l'heure actuelle, j'en sais rien ... mais je trouve bien risqué de la part d'une entreprise de dire ... l'application que je developpe est un investissement pour les 5 à 10 prochaines années, comme mes clients sont pour le moment tous sous windows, autant faire du dotNet, ca coutera d'autant plus cher si le vent tourne en faveur de Linux ou macOs


Personnellement je ne vois pas l'interret de m'enfermer chez un vendeur logiciel, surtout quand on voit comment il a abandonné les utilisateurs VB en disant, voila Vb.net, c'est plus compatible, demerdez-vous... Comment savoir quel est la prochaine technologie qu'il va abandonné ?

[neo.51]

Je ne pense pas que la tendence s'inversera autant dans 5-10 ans. Même si linux gagne du terrain, on oublie souvent nous informaticien l'utilisateur lambda. L'utilisateur lambda n'aura pas linux sur son poste pour demain. Sans rentrer dans les détail je développe des applis de gestion pour des associations de communes. Ils sont équipés depuis à peinne 2 ans 5 ans pour les plus modernes. Complètement néophyte de l'info. La pluspart des gens se sont formé sur windows et je me vois mal leur dire de se mettre sous linux. Bref je m'éloigne un peu du débat.

Mais sachant que tous mes utilisateurs finaux sont sous windows, et à mon avis ne sont pas prés de changer car il commencent à peinne à le maitriser ! Je prèfère utiliser du C#, qui s'intègre parfaitement dans l'ensemble des produit microsoft. Et qu'on le veuille ou non c'est comme ça ! je ne dis pas que c'est bien mais c'est une réalitée énormément de gens qui se sont informatisé sont informatisé microsoft !

J'utilise donc le C# qui me permet d'avoir l'interface graphique la plus rapide possible et une intégration maximales dans les produit microsoft. C'est à moi à m'adapter à mon client, pas l''inverse !

Aprés au niveau des serveur d'application, il est vrai que linux semble moins couteux et plus fiable que windows. Mais mois perso ça ne me poserai aucun cas de conscience d'avoir des webservice en java concomés par des applis C#.

[Traroth]

Ce qui est sur, c'est que la portabilité n'est pas genante en soit, d'autant que d'après ce qu'on me dit (encore une fois, je n'ai pas testé), SWT marche plutot bien. C'est plus simple que Swing et plus rapide. Ton application aura un look dependant de la machine, mais ça reste portable. Pour ce qui est de l'interet de la portabilité, il y a encore 3 ans, le débat semblait clot : c'etait Windows sur le poste client ou rien. Maintenant, des alternatives, comme Linux, ou MacOS, qui reprend du poil de la bete, existe, et gagnent des parts de marchés (alors que tout ce qui pouvait exister il y a 3 ou 4 ans ne faisait qu'en perdre). Se couper de tout ce phenomene sans raison speciale, finalement, ça me parait etrange, comme raisonnement. Pour ce qui est de Swing, je ne pense pas que les problèmes actuels soient une fatalité. Il faudrait que Sun en mette un bon coup, pour obtenir un produit bien fiabilisé, c'est tout. Mais on a l'impression (je sais, c'est subjectif) que Sun est plus interessé par les plateformes mobile (J2ME) et serveur (J2EE) que par la plateforme client lourd (J2SE et surtout JFC). Mais il y aurait surement un bon coup à jouer

[thecat]

pourquoi c# est un mauvais langage objet .... rapidement:
C# conserve le mot clef "virtual" qui est une abérration pour un langage objet moderne, qui est en plus basé sur une VM ... Cette scorie est tellement enorme que cela descend le langage et ses concepteur: soit ceux qui ont fait le langage ne comprennent rien à l'objet et ont fait n'importe quoi (peu probable) soit c'est le marketing qui à dit au développeurs de faire un langage "comme C++" (qui lui était déja un trés mauvais langage objet, mais il pouvait ce defendre dans l'esprit par lequel il se voyait: tous sacrifier pour une execution rapide.). C# est basé sur une VM, donc conserver toute les disgrétion de C++ est nul.

Il y à d'autre exemple (mais je ne pourrais tous les expliquer précisement et rapidement) mais rien que celui-ci fait qu'il ne faut pas promouvoir ce langage.
Java avait à l'époque fait un grand pas avec son (preque)tout référence, son garbage collector, ses interfaces, sont typage statique .... il à amener quelque chose de plus qu'il fallait conserver. C#, pour un nouveau langage, reprend les défaut les plus criticable de ses prédécesseur ... pourquoi alors l'utiliser ?

[Traroth]

Je gage que tu parles des classes declarées virtual (pour ceux qui ne savent pas, c'est pour gerer une ambiguité de l'heritage multiple : si une classe A herite de 2 classes B et C, qui elles meme heritent d'une classe D, on va retrouver les elements de D en doublon dans A. Pour empecher cela, on declare B et C en virtual). Evidemment, Java ne permet pas l'heritage multiple (sauf pour les interfaces, mais là, pas de doublon possible, puisqu'on ne peut pas avoir 2 methodes avec le meme prototype). Ca simplifie le probleme. Pas besoin du mot clé virtual. Mais on pourrait facilement reprocher à Java l'approche simpliste de la question : l'heritage multiple peut poser des probleme, alors on l'interdit completement. C'est un peu dommage, meme si on peut se feliciter de la simplification, par ailleurs.
Ce que je veux dire, c'est que Java a, sur cette question, un parti pris different de C++ et C#, voila tout. Ca ne veut pas forcement dire meilleur.

[thecat]

J'ai pas dut comprendre le post du dessu car:

c# n'accepte pas non plus d'héritage multiple. Seul le sous typage multiple est possible grace au interface (comme en Java). La plateforme .Net est prevu pour un héritage simple, donc c'est déja pas evident d'implémenter un langage à héritage multiple dessu (precisons que eiffel# l'a fait -heritage multiple sur .Net- mais au prix d'une certaine bidouille dans leur compilo, il faut biens l'avouer). Donc Java et C# non rien à se reprocher l'un contre l'autre usr ce coup la...

Le virtual qui est inadmissible est celui des méthodes, que l'on doit expliciter partout (aberration: vous ètes dans un langage dit "objet" mais vous devez specifier partout que vous desirez la selection dynamique des methode -le virtual-, qui est une caracteristique indispensable pour ètre qualifier de langage "objet")

D'autre problèmes vienne quand on lit les explications du lagage: souvent on parle de l'implémentation des objet, on parle d'allocation dans la pile, dans le tas, tous ca pour "coller" un peu plus à C++ .... Non mais on rigole ou quoi? c# va ètre compilé pour une VM, on s'en fous si c'est dans la pile ou dans le tas! En plus il pourra ètre recompilé vers du natif aprés, qu'est-ce que vous en avez à faire dans quelle partie de la mémoire cela va ce situer ... pourquoi ne pas pouvoir spécifier de rester dans le cache du processeur? ou meme dans quelle barette memoire balancer notre objet tant que l'on y est! .... Java avais reussi a faire une reele abstraction de cela, et C# reviens en force avec tous ces anciens problèmes ... tiens d'ailleur, c# à t-il garder le "goto"? (je sais pas mais ca me ferrais bien marrer)

J'ai étais un peu méchant dans le paragraphe precedent mais bon, quand le marketing se mèle du développement d'un nouveua langage, et bien c'est pas joli ... (je dit "marketing" car je n'ose penser que ce soit réélement les concepteur du langage qui aient laisser c'est scories)

[Traroth]

Oups. J'avoue ne pas bien connaitre C#. J'avais simplement deduis de ton post (à tort) que c'est de l'heritage multiple dont tu parlais. Mais ça ne change pas grand chose au fond de mon post.
Les possibilités "proches du système" ne sont pas forcement une mauvaise chose, puisqu'elles permettent eventuellement une plus grande optimisation. D'un autre coté, ça permet moins d'abstraction, je suis d'accord. C'est encore une fois une question de point de vue. Avec Java, le parti pris est clairement de tout laisser gerer par le systeme. C'est un parti pris excellent si le systeme gere correctement les choses, ce qu'il fait dans 99% des cas. Mais le 1% restant ? Je suis d'accord pour dire que Java a innové, dans le sens où il permet de ne pas se preoccuper de tout un tas de choses, mais la reputation que traine Java (lenteur, manque de fiabilité pour des applications critiques), de moins en moins meritée, vient clairement de là.

[neo.51]

Le c#, marche sur ce même principe :

code C#=>langage intermédiaire=>framework.

Seulement c'est un framework optimisé pour windows et en pert pour le moment sa compatibilité avec les autres os.

je ne vois pas dans le post ci dessus quel argument diférencie java de C#.

C# ou java, il est dificile de dire quel est le meilleur langage sachant que tous deux sont de bon langages orientés objet. Aprés c'est le framework et le compilatteur utilisé qui permettent de vraiment le différencier...