Discussion :

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

[sambarbas]

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 ?

Oulah ! faut faire un peu attention à ce qu'on dit parfois... J'avais zappé ce morceau de choix. Pour coder régulièrement dans les 2 langages, je me dis souvent l'inverse. Java n'est pas un bon langage objet.

Si tu parles du mot clé virtual, ne pas l'implémenter me parait une abération complète. De même pour override bien sur. Je n'arrive pas à comprendre ce choix, cad la possibilité d'étendre, voire même modifier le comportement d'une méthode parente sans qu'elle soit autorisée ni même déclarée. Je serai une classe je crierai au viol !

D'ailleurs il me semble que ce genre de comportement a été ajouté en 1.6, à confirmer mais dans ce cas thecat revoit ton point de vue sur le sujet

[adiGuba]

Si tu parles du mot clé virtual, ne pas l'implémenter me parait une abération complète. De même pour override bien sur. Je n'arrive pas à comprendre ce choix, cad la possibilité d'étendre, voire même modifier le comportement d'une méthode parente sans qu'elle soit autorisée ni même déclarée. Je serai une classe je crierai au viol !

En Java toutes les méthodes sont virtual (sauf les méthodes private), et il est possible d'empêcher toutes redéfinitions en utilisant le mot clef final. Perso je ne vois pas vraiment l'intérêt du mot-clef virtual...

La principale différence à mes yeux c'est qu'en C++ il est possible de déclarer dans une classe fille une méthode avec la même signature qu'une des méthodes de la classe parente, sans qu'elle ne la redéfinisse (lorsqu'elle n'est pas virtuel) : les deux méthodes sont totalement distinctes bien qu'elles aient le même nom et les mêmes paramètres...

D'ailleurs il me semble que ce genre de comportement a été ajouté en 1.6, à confirmer mais dans ce cas thecat revoit ton point de vue sur le sujet

Le final est présent depuis toujours... mais tu veux peut-être parler de l'annotation @Override qui est apparut avec Java 5.0 pour "signaler" les redéfinitions de méthode ?

a++

[davcha]

En Java toutes les méthodes sont virtual (sauf les méthodes private), et il est possible d'empêcher toutes redéfinitions en utilisant le mot clef final. Perso je ne vois pas vraiment l'intérêt du mot-clef virtual...

Franchement, c'est pareil.

Entre java où tout est virtual, sauf si tu précises final ou c# où tout est "final" sauf si tu précises virtual....

voilà quoi...

La seule différence est philosophique.

[adiGuba]

Franchement, c'est pareil.

Entre java où tout est virtual, sauf si tu précises final ou c# où tout est "final" sauf si tu précises virtual....

Oui c'est bien ce que je dis. Je répondais à sambarbas qui critiquait l'absence du mot-clé virtual en Java...

Perso la seule chose qui me chiffonne c'est de pouvoir définir une méthode avec la même signature qu'une méthode non-virtuelle de la classe parente, sans que ce soit une redéfinition. Mais puisque C# affiche un warning c'est déjà bien moins gênant

Après comme tu le dis c'est plutôt philosophique et cela révèle une approche un peu différente de la POO... mais on final on retrouve les mêmes mécanismes !

a++

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

[thecat]

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

[Traroth]

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.