C# versus Java

Citation:

---

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

---

c'est jamais que 10 lignes de code.

Citation:

---

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

Citation:

---

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 !

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.

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.

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é

Citation:

---

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

Citation:

---

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

---

Citation:

---

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#

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

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 ?

Citation:

---

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 !

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 ?

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

J'ai encore d'autres questions :

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

:arrow: 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 ?

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.

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

Citation:

---

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 !

Citation:

---

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

Citation:

---

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

Citation:

---

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é ?

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#.

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

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 ?

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.

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)

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à.

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

Citation:

---

Envoyé par neo.51

C# ou java, il est dificile de dire quel est le meilleur langage sachant que tous deux sont de bon langages orientés objet.

---

Non! C# n'est pas un "bon" langage objet. lit les posts du dessu.
Si l'on pousse le vice un peu plus loin (mais pas bcp plus ...) on peut même dire que c# n'est un langage "Objet" que de justesse! La selection dynamique des méthode est une propriétée ESSENTIELLE d'un langages pour etre qualifier de "objet". Devoir être obliger de le spécifier (avec le mot clef 'virtual') fait, dans un sens, que l'on est obligé de dire au langage "d'etre objet".

Java est quand meme un meilleur langage objet, meme si il n'est pas parfait. C# est un nouveau langage qui n'est pas meilleur, et même pire, donc il ne faut pas l'utiliser.

Pour Taroth: Pouvoir, dans un langage, spécifier des contrainte d'implémentation (inlining, allocation pile/tas) et trés dangereux, compliqué, sujet à bug, et va à l'encontre d'un langage objet moderne (toujours + d'abstraction pour gerer de plus gros projet/applications, meilleur compilo qui ferrons le boulot pour toi et mieux que toi). De plus C# va touner sur une machine virtuelle, tu croit vraiment gagner bcp de perf en bidouillant avec ta VM ? Je ne pense pas, ou alors au prix de tellement d'effort que cela ne vaudra pas le coup. Les bug coutent biens plus chers que quelques cycle d'horloge. Mais c'est vrais qu'il ne faut pas ce satisfaire de la "lenteur" des langages ;)

Là, je t'arrete : la question ne se pose pas en ces termes. L'optimisation est un sujet essentiel. Qu'une application soit optimisé ou non, c'est ce qui va determiner le nombre d'utilisateurs qui pourront se connecter simultanement à un site Web, par exemple (c'est pas le seul facteur, on est d'accord), toutes choses etant egales par ailleurs. Et penser qu'un compilateur peut faire mieux qu'un programmeur dans ce domaine, ça n'est pas serieux.

L'optimisation est importante je ne le nie pas, mais un compilo ferra beacoup mieux que toi et beaucoup plus proprement et surement ... regarde, rien que le garbage collector, c'est 'lourd' et couteux en ressource mais son interet est indeniable! L'inlining peut trés biens etre géré par le compilo (certains le font ...), la selection dynamique peut même être suprimé par le compilo quand elle est inutile pour accelerer l'appel de méthode et tu n'a toujours pas à t'en occuper!

Cepandant je suis d'accord que parfois, il faut "mettre les mains dans le combouis" mais pas pour ton application entierre!, pas de manierre systématique! beaucoup d'application tourne trés biens sans optimisation "qui vont biens car l'allocation en mémoire ce fait sur des addresse paire et patatipatata" ;) regarde Java!

De plus, C# ce base sur une VM, qui est une abstraction de l'architecture sous-jacente; Reflechir à une optimisation pour une abstraction ? sa sonne un peu faux non? ;)

Je ne reni en aucun cas l'utilité de l'optimisation, ni la nécessité! Mais elle doit etre exeptionelle pour le langage (surtout pour un langage moderne, objet, et tournant sur une VM), et ce langage ne doit pas obliger le développeur à y reflechir à chaque ligne de code.

Citation:

---

rien que le garbage collector, c'est 'lourd' et couteux en ressource mais son interet est indeniable!

---

Excellent exemple : Si tu programme correctement tes allocations et desallocations, ça ira beaucoup plus vite qu'avec un garbage collector.

Citation:

---

ce langage ne doit pas obliger le développeur à y reflechir à chaque ligne de code

---

Comme dit, je ne suis pas un pro de C#, mais je ne pense pas qu'on en soit là

Citation:

---

Je ne reni en aucun cas l'utilité de l'optimisation, ni la nécessité! Mais elle doit etre exeptionelle pour le langage

---

Le problème est qu'il est difficile d'optimiser en Java, en particulier en ce qui concerne la gestion memoire. C'est assez "piegeux", en fait. L'optimisation en Java, ça peut signifier utiliser plutot des variables locales que des variables de classes, par exemple. Pas très evident, à premiere vue.

Citation:

---

Excellent exemple : Si tu programme correctement tes allocations et desallocations, ça ira beaucoup plus vite qu'avec un garbage collector.

---

Le principe du code manager, c'est justement de pas te laisser le controle de la memoire... Le "si tu programme correctement" implique qu'il existe une facon de pas le faire correctement... De plus les garbage collector actuelle sont largement optimisé et ne sont plus si couteux que ca !

Citation:

---

Le problème est qu'il est difficile d'optimiser en Java

---

Oui, mais c'est pas toi qui optimise, c'est le JIT, chaqu'un sont boullot !
De plus, c'est pas très compliqué de comprendre que l'acces a des variables locales est TOUJOURS plus rapide que des variables de classes... pour le reste, laisse les compilo se debrouiller !

Ces remarques sont valables quelque soit le langage.

Citation:

---

Le "si tu programme correctement" implique qu'il existe une facon de pas le faire correctement

---

Exact. C'est comme ça pour tout. C'est pour ça que la programmation necessite un vrai savoir-faire et qu'on peut en faire son metier.

Citation:

---

Oui, mais c'est pas toi qui optimise, c'est le JIT, chaqu'un sont boullot !
(...)pour le reste, laisse les compilo se debrouiller !

---

C'est ce type de raisonnement qui produit la qualité de code actuelle, souvent execrable en dehors du monde du logiciel libre (où les gens fignolent et optimisent, justement)

Citation:

---

De plus, c'est pas très compliqué de comprendre que l'acces a des variables locales est TOUJOURS plus rapide que des variables de classes...

---

Pour le gars qui ne connait que les principes abstraits du langage, je pense que ça n'a rien d'evident.

Je suis tout a fait opposé à thecat quand il dit qu'il ne faut pas utiliser C# (au profit de Java). Et cela pour plusieurs raisons. Notament celle mentionnée pas neo.51: pourquoi se fatiguer a faire des applications portables sur linux, solaris, unix et autres alors que le client ne demande qu'un programme windows? Pourquoi se fatiguer a utiliser des fonctions de Java alors que pour windows, celles de l'Api semblent mieux convenir.
Je crois que crois que thecat manque lourdement d'impartialité dans son attaque contre C#; il me semble qu'il vaut mieux regarder ce debat avec tempérance, et adapter sa réponse en fonction de ce qu'on demande au programme; il n'existe pas de "meilleur" language; il existe juste des languages qui conviennent mieu à une situation donnée!

en tout cas, visiblement, C# n'est pas tellement plus rapide que java (voir moins rapide) pour les operations de base
http://www.tommti-systems.de/main-Da...enchmarks.html

faut aller jusqu'en bas de l'article

Citation:

---

Envoyé par okeefe

même si mono est là, je vois pas pourquoi j'irais foutre du ms dans un système linux... on choisie linux par choix, c'est certainement pas pour apporter les bug ms avec nous

---

Euh... de quoi tu parles là??
il n'y a aucun code provenant de microsoft dans mono.

Citation:

---

Envoyé par lunatix

en tout cas, visiblement, C# n'est pas tellement plus rapide que java (voir moins rapide) pour les operations de base
http://www.tommti-systems.de/main-Da...enchmarks.html

faut aller jusqu'en bas de l'article

---

Nan là je suis obligé de réagir là parce qu'apparemment il y en a qui ne savent pas compter et lire anglais. Parce qu'en lisant l'article, C# bat java de loin. Et en plus, que vois-je?

Citation:

---

Envoyé par le site en question

they seems to use some lower precision for the sin, cos and tan functions

---

En plus de se faire sodomiser sec sur les temps de calcul, les opérations sur les virgules flottantes sous java sont imprécises et très lentes. Et ça veut être serieux avec ça.

Pour confirmer les choses, j'ai fait le test chez moi avec les valeurs maximales divisées par 10 pour ne pas attendre 5min devant l'ordi :
résultat :

Citation:

---

Total C# benchmark time: 7529 ms
Total Java benchmark time: 19265 ms

---

Java prends 2,5 fois plus de temps sur ma machine. Ridicule.

je prends le debat un peu au bond et donc je n'ai pas vraiment suivit les evolution mais ce que je peux dire cest que je suis autant java que c#. Je m'explique # a bel et bien copie sur java beaucoup de chose mais remarquer que java avec la futur version 1.5 fait de meme sur son omologue ex : les propriété en c# ...

DE plus c# plante mais pas autant que ce qu'on peut le dire. Par exéprience j'ai réalisé un serveur en java et en c# et je dois dire que en java fin de semaine je devais rebooter la machine car la machine virtuelle ne suivait plus et j'avais quand meme 1giga de ddr en ram donc ...

Avec mon serveur c# moins de probleme.

J'attends vos réaction tout en me faisant l'avocat du diable

Citation:

---

Nan là je suis obligé de réagir là parce qu'apparemment il y en a qui ne savent pas compter et lire anglais. Parce qu'en lisant l'article, C# bat java de loin. Et en plus, que vois-je?

---

Après avoir longuement parcouru l'article en question, je suis très étonné de voir que les performances de Java sont dans la majorité des cas supérieures au C# (les perfs sont en milli secondes, donc plus bas c'est mieux). Mieux vaut bien lire avant de réagir violemment.


Il est intérressant de noter la grosse faiblesse de la VM de sun pour les opérations mathématiques , et celle du C# pour la gestion des listes...

Ce ne sont que des tests très précis, et dans tous les cas je pense que C# offrira toujours des perfs meilleures sous windows ne serait-ce ce que parce qu'il nécessite moins de mémoire.
Je pense que cet écart sera d'autant plus grand que l'application va utiliser des composants graphiques, et là nous verrons que le C# est bien plus rapide que Java.

Enfin je ne pense pas que la peformance soit un critère déterminant, ni le C# ni le Java n'ont été conçus dans l'optique de performances fulgurantes, les langages compilés restent indétrônable, et sincèrement je m'en contrefiche un peu de savoir si mon programme Java va mettre 10ms de plus ou de moins à effectuer un calcul compliqué, car ce qui détermine avant tout les performances d'une application c'est la qualité du code du programmeur.


En fait un tel test permet surtout de comparer les machines viruelles.

Citation:

---

En plus de se faire sodomiser sec sur les temps de calcul, les opérations sur les virgules flottantes sous java sont imprécises et très lentes. Et ça veut être serieux avec ça.

---

Un peu de tenue, de respect, et un langage chatié ne seraient pas du luxe, pourquoi es-tu aussi agressif?

Enfin :

Citation:

---

they seems to use some lower precision for the sin, cos and tan functions

---

S'applique vraissemblablement uniquement à JET 3.5, qui offre malgré tout des performances similaires à C++ et C# sur le test trigo, encore une fois il faut lire le texte.

il y a aussi ce bench:

http://www.osnews.com/story.php?news_id=5602

mis à part la trigo java s'en sort très bien...

le code pour .net n'est pas managed... mais il affirme qu'il y a pas de gain de performance... j'ai des doutes mais bon....

nicoo, c'est pas parce que ça plante chez toi que c'est partout pareil...si java serait aussi minable que ça et planterais autant, il ne serait jamais autant utilisé sur les serveur

faut pas s'attendre à des miracles de mono, c'est pas ms qui fait le boulot donc ils seront toujours en retard par rapport à eux et absolument rien ne garantie que ça sera pleinement fonctionnel avec ce qu' ms fait

[quote="iolco51"]

Citation:

---

Ce ne sont que des tests très précis, et dans tous les cas je pense que C# offrira toujours des perfs meilleures sous windows ne serait-ce ce que parce qu'il nécessite moins de mémoire.

---

bof bof c'est pas toujour vrai de plus... avec ce que windows nécessite en ram et surtout avec leurs prochain version... si on a pas de ram on peut pu faire grand chose

Citation:

---

Je pense que cet écart sera d'autant plus grand que l'application va utiliser des composants graphiques, et là nous verrons que le C# est bien plus rapide que Java.

---

trop souvent les gens concoivent leur gui en java de façon incorrecte, ce qui amène a une gui lente...

ta plein de programme qui le montre telle que jajuk, jbuilder et cie

c'est aussi vrai pour le code des prog...
juste en retouchant une partie de prog de téléphonie qui utilisait énormément les string, les performances ont augement de 400%
merci les stringbuffer :)

ta de nombreux site expliquant les optimisants pouvant être fait en java...

faut regarder et savoir coder avant de critiquer

Citation:

---

faut regarder et savoir coder avant de critiquer

---

Ce n'est plus savoir coder que de connaitre les bricolages nécéssaires d'un langage pour faire tourner à vitesse normale un programme.

Java n'est pas fait pour faire des interfaces graphiques. Ou plutôt les concepts utilisés dans Swing sont trop lourds.

Chaque langage a ses avantages et ses inconvénients. Aucun langage ne sait tout faire mieux que les autres. N'importe quel consultant technique sérieux vous le dira.

Concernant Swing, je dirais que ce framework est d'une lourdeur inimaginable, et d'une lenteur sidérente sur des machines actuelles. A force de vouloir trop bien faire (MVC à tout va), on en arrive a ne plus savoir rien faire correctement. Qui oserais comparer la VCL de Borland a Swing de Java? Je n'ose même pas en dire plus, préférant ne pas penser au centaines de lignes de codes nécéssaires pour faires des choses simples en Swing faites en quelques clicks de souris en VCL sous Delphi ou C++ Builder par ex, ni à la différence d'execution. Sans parler des bugs de JDK, toujours reglés ou améliorés dans le JDK suivant, ni même des invokeLater, qui sont une véritable plaie pour le débuguage et les performances.

Bref, jugement sans appel. Java très bien pour les wepApp. .Net fera-t-il mieux de ce côté là? Niveau applications et interfaces graphiques, je demande à voir ce que va nous faire .Net. En attendant, je resterais sur Delphi 8 .Net et la VCL qui tourne tellement bien depuis tant d'années.

Citation:

---

trop souvent les gens concoivent leur gui en java de façon incorrecte, ce qui amène a une gui lente...

ta plein de programme qui le montre telle que jajuk, jbuilder et cie

c'est aussi vrai pour le code des prog...
juste en retouchant une partie de prog de téléphonie qui utilisait énormément les string, les performances ont augement de 400%
merci les stringbuffer

ta de nombreux site expliquant les optimisants pouvant être fait en java...

faut regarder et savoir coder avant de critiquer

---

Je ne critique pas, mais j'enonce une realite.

L'API Swing est tres bien pensee, bien documentee, et c'est un regal de developper des applications avec.

Mais optimisations du programme ou non, une interface graphique en swing sera toujours bcp fois plus lente qu'une interface native, c'est lie a l'architecture de swing, et au choix de sun (que je trouve judicieux) de ne (presque) pas utiliser de composants natifs.

On a beau la critiquer, swing reste une excellent librairie destinee aux interfaces graphiques, aux performances tout a fait honnete, avec un look and feel pluggable, une tres bonne architecture (MVC entre autres), et 100% portable avec ca. On ne peut pas etre bon partout.

Une chose n'a pas été dite sur la question de la portabilité. On dit que C# devrait à court terme être portable sur Linux. Seulement, il y a linux et linux (Suse, Redhat, Mandrake,RHEL3...et j'en passe)

Et une version de linux n'est pas du tout l'autre :P

Je le constate de plus en plus souvent car mon entreprise a introduit sur le marché(il y a + de 10 ans) un spooler d'impression hyper complet portable sur TOUTES les plateformes sans exception (comme ce spooler est certifié par SAP, faut suivre SAP).

Mais celles qui nous posent régulièrement des problèmes sont les Linux.

Linux est hyper dur à suivre, les kernels changent tout le temps... A chaque release de Redhat, des problèmes apparaissent. Bref, c'est pas une mince affaire de suivre Linux. Les systèmes Unix eux sont plus beaucoup plus homogènes (AIX, HP,Solaris). Microsoft devrait peut-être d'abord s'attaquer à Unix plutôt qu'à Linux.

Citation:

---

Envoyé par stephaneey

Une chose n'a pas été dite sur la question de la portabilité. On dit que C# devrait à court terme être portable sur Linux. Seulement, il y a linux et linux (Suse, Redhat, Mandrake,RHEL3...et j'en passe)

---

Citation:

---

Envoyé par stephaneey

Linux est hyper dur à suivre, les kernels changent tout le temps... A chaque release de Redhat, des problèmes apparaissent. Bref, c'est pas une mince affaire de suivre Linux.

---

Je ne vois pas en quoi le changement de noyau peut influer négativement sur le portage du C#.
J'ai installé la même jvm sur des 2.4 et 2.6 et je n'ai eut aucun problème.
Sun n'a pas de problème majeur avec ça.
Et sur le fait que C# soit portable sous Linux à court terme j'ai des doutes.
De toute façon, la majorité des Linuxiens sera plus que réticente à coder en C#.

Personnellement, j'ai répondu Java.
D'abord, je pense qu'un bon programmeur doit être ouvert sur tout les langages. On ne sait jamais, parfois on découvre un langage qui nous servira mieux.

Pour justifier mon je dirai que le Java est un langage complet. La communauté Java offre une multitudes d'outils et de plate-forme qui répondent à nos besoins (J2EE, J2ME,...) ainsi que des IDE de performances inégales.

Je vois que le C# apporte peu (pour ne pas dire il n'apporte presque rien) au Java. On a Java, il répond à nos besoins alors pourquoi le C#?
En terme de gestion de temps et de mémoire, je reconnais que le C# présente un plus par rapport à Java, mais par rapport à d'autre avantages (richesse de la bibliothèque Java,...), on peut s'en passer.

Voilà mon avis, merci à tout.

je rajoute une chose, java a contribué je trouve à apporter de nombreux outils de qualité au développement, des méthodes de travail....

par exemple niveau patron, on cherche sur le net et la plupart du temps, tout est donné pour java

Citation:

---

Envoyé par rurouni alex

Et sur le fait que C# soit portable sous Linux à court terme j'ai des doutes.

---

...et pourtant Mono est maintenant là...et ça marche plutôt bien.
Mono n'est pas "en retard" d'un train par rapport aux avancées du framework d'origine, et cela augure plein de bonnes choses pour l'avenir.

Citation:

---

Envoyé par rurouni alex

De toute façon, la majorité des Linuxiens sera plus que réticente à coder en C#.

---

Ah bon, et pourquoi ? Par pure réaction anti-microsoft primaire et idiote ?