Précédemment, Microsoft clamait la superiorité de son framework sur J2EE. Suite à de vives protestations sur les conditions de tests et les différentes architectures logicielles et materielles utilisées, le test a été refait afin de convenir à la majorité des attentes.
Le résultat parle de lui meme : dotNet l'emporte largement. PetStore est une application type permettant d'expliquer tous les concepts de J2EE. Précédemment, Microsoft a implémenté la même chose utilisant dotNET, de facon plus performante et en moins de lignes de code.
The MiddleWare Compagny a effectué un test de performances comparant J2EE et dotNET en recodant les 2 applications pour les mettre sur un pied d'égalité. Le résultat est impressionant .. dotNET l'emporte largement.
Prochaine étape, aller faire un tour du côté de Mono ?
Aller plus loin
- L'artice sur TheServerSide (68 clics)
- Le resultat du test ( PDF ) (76 clics)
- La page ches The MiddleWare Compagny (21 clics)
- L'ancien article (9 clics)
- Ancien comparatif vu par TheRegister (12 clics)
- PetStore (12 clics)
# Re: Benchmark J2EE vs dotNET
Posté par Schwarzy . Évalué à 1.
http://dreambean.com/petstore.html(...)
A l'origine, cette application en java a été pensée pour montrer un design trés propre, pas pour montrer une implementation performante. M$, enfin, ceux qui sont payé par M$, la MiddleWare Compagny, on surement choisi cette application car ils étaient sûr d'être largement supérieurs en terme de performance. Surtout que la version .NET n'est pas un copié conforme en terme de design.
Cette comparatison semble mettre façe à façe des pommes et des oranges. Bref, c'est du marketing pur et dur et non de l'évaluation technique avec un minimum d'honneté.
Attention aux trolls !
[^] # Re: Benchmark J2EE vs dotNET
Posté par pasBill pasGates . Évalué à 1.
Mon petit doigt (celui de la main droite pour les curieux) me dit que cette boite voulait se faire un bon gros coup de pub, et ca marche vu qu'on a parle d'eux sur Slashdot et linuxfr.org qui rappelons le, et le 2eme site le plus visite apres ./ :+)
[^] # Re: Benchmark J2EE vs dotNET
Posté par anonyme512 . Évalué à 1.
http://developers.slashdot.org/article.pl?sid=02/10/30/1345214&(...)
bref, je serais d'avis de dégager cet article dans la boite autre, c'est un débat tout à fait stérile.
par ailleurs, les points techniques soulevés en ce qui concernent la différence entre les deux applis sont très intéressants, avec des points assez frappants:
la version microsoft mélange la couche business et data, ce qui apporte des gains très importants en performance, et en termes de LOC.
le test initial comparait en effet aussi le nombre de lignes de code (2000 pour .NET et 14000 pour J2EE), mais là encore il y a clairement eu de l'abus en gonflant artificiellement le nombre de lignes de J2EE (copier-coller artificiel de méthodes, au lieu de les encapsuler dans une classe utilitaire dédiée)....
bref, du grand art en termes de désinformation
[^] # Re: Benchmark J2EE vs dotNET
Posté par anonyme512 . Évalué à 1.
rectificatif: en ne dégonflant pas le nombre de lignes de code de l'appli J2EE, alors qu'ils clamaient avoir revu l'appli avant de faire les tests.
en effet, ce n'est pas l'appli de Sun qui est testée, mais une version revue et soit-disant hyper améliorée par TMC.
# ça sent le roussi !
Posté par Samuel Pajilewski . Évalué à 1.
Etant moi meme un farouche partisan de J2EE et de Java, je ne peux qu'avouer que .Net est franchement plus rapide et puissant que celui-ci :-(
Il serait souhaitable que Microsoft developpe lui meme .Net pour Linux, Solaris, HP-UX, Mac OS... comme cela on aurait quelque chose d'universel.
Tant que Microsoft fera du 100% Windows, J2EE aura du temps encore avant de disparaitre...
[^] # Re: ça sent le roussi !
Posté par anonyme512 . Évalué à 1.
1- les XPs reviennent sur linuxFR
2- avant de te précipiter pour poster, tu attendes et que tu lises d'autres commentaires, si tu as la flemme de chercher un autre son de cloche sur le net.
[^] # Re: ça sent le roussi !
Posté par phneutre . Évalué à 1.
et la tyrannie continue.
[^] # Re: ça sent le roussi !
Posté par anonyme512 . Évalué à 1.
donc soit les XPs reviennent, soit les gens se réfrènent, sans quoi pour tous ceux qui ont pas que ça à foutre de lire linuxfr toute la journée, ça va devenir illisible.
certains articles récents dépassent la centaine de commentaires, parce qu'un troll a démarré ou qu'un mec a pas voulu lâcher le morceau sur son point de vue. avant ça faisait un blob de (-1), on passait dessus sans s'en préoccuper, d'autant que les commentaires pertinents ressortaient.
maintenant ça donne des pages de commentaires illisibles et qui prennent beaucoup trop de temps à lire. donc en l'absence de système de modération, ce serait cool que les gens apprennent à se retenir..... c'est un voeu hyper pieu qui a pas bcp de chance de marcher, mais bon.
en tous cas, rien à voir avec la tyrannie, c'est juste une sorte de respect du lecteur d'éviter ce genre de bordel, sans quoi, autant aller troller sur hfr ou sur slashdot (et encore, sur /. ya de la modo)
[^] # Re: ça sent le roussi !
Posté par Samuel Pajilewski . Évalué à 1.
J'ai juste regard" les graphiques, j'en suis stupéfait
[^] # Re: ça sent le roussi !
Posté par Yusei (Mastodon) . Évalué à 1.
[^] # Re: ça sent le roussi !
Posté par sToR_K . Évalué à 1.
Tu sais pas lire? Tu ferais bien d'apprendre, ça t'évitera de dire des conneries et de passer un peu moins pour un con...
pfff..
[^] # Re: ça sent le roussi !
Posté par David Pradier . Évalué à 1.
Ce sont des appels permanents au troll, et compris en tant que tels.
Alors bon, pas la peine de lui fermer sa gueule, soit vous aimez vous lancer dans le troll et vous lui répondez (de préférence avec une mauvaise foi bien visible), soit vous l'ignorez :-)
Perso, j'aime bien les posts de sam, ils apportent une réelle fraîcheur. On sent le gars étonné, franc, ouvert et prêt à tester le logiciel propriétaire au péril de son âme. Ce serait dommage que le retour des XP nous prive de sa contribution (si si, je suis vraiment de cet avis :-).
Par contre, sam, stp utilise des balises <sérieusement></sérieusement> le jour où tu voudras dire qqch de sérieux :-)
[^] # Re: ça sent le roussi !
Posté par Anonyme . Évalué à 1.
Il y'a beaucoup d'autres endroits où les gens parlent ainsi... et c'est tout ce qu'il y'a de plus sérieux.
[^] # Re: ça sent le roussi !
Posté par David Pradier . Évalué à 1.
Non :-) ??
[^] # Re: ça sent le roussi !
Posté par David Pradier . Évalué à 1.
# Re: Benchmark J2EE vs dotNET
Posté par kruskal . Évalué à 1.
Ca aurais été plus dans l'esprit du libre......
# Re: Benchmark J2EE vs dotNET
Posté par asteroidZ . Évalué à 1.
http://www.dotnetguru.org/article.php?sid=79(...)
-ast
# Re: Benchmark J2EE vs dotNET
Posté par Stéphane Traumat (site web personnel) . Évalué à 1.
Est ce vraiment le plus important ? si un mec postait un benchmark disant : "les performances de J2EE et .Net sont trop mauvaises !!! on a comparé à notre version de pet store réalisée des CGI en C et on tourne 2 fois plus vite "
Ca vous choquerait vraiment ? si les performances étaient si importantes, on programmait tous en C et on ne ferait pas d'objet !
Donc, peut etre que J2EE est moins performant mais bon... c'est pas le plus important, des choses comme CMP, JNDI... font l'interet de la solution et je doute que beaucoup de personnes ont pris J2EE pour ces performances...
Pour information, j'ai écrit un article d'introduction à J2EE : http://www.ashita-studio.com/articles/j2ee/introduction_J2EE.html(...)
a+
TrOm
http://about.me/straumat
[^] # Re: Benchmark J2EE vs dotNET
Posté par ldng . Évalué à 1.
[^] # Re: Benchmark J2EE vs dotNET
Posté par patton . Évalué à 1.
[^] # Re: Benchmark J2EE vs dotNET
Posté par tcws . Évalué à 1.
-1 pour moi mais alors + au dessus quand même.
[^] # Re: Benchmark J2EE vs dotNET
Posté par pacman . Évalué à 1.
Pour comparer ces plateformes il faut se baser sur d'autres critères : le temps qu'on met pour créer une appli, les outils de développement, le support, l'indépendance vis à vis du contructeur....
Pour moi, la grande force de .NET est sa standardisation : ECMA, ISO. Quand la version libre Mono sera achevée, on aura réellement quelque chose d'intéressant.
Le gros avantage de J2EE est tout le savoir-faire qu'il existe autour de cette plateforme. J2EE est une solution qui a fait ses preuves.
[^] # Re: Benchmark J2EE vs dotNET
Posté par Moby-Dik . Évalué à 1.
Le truc c'est que si à niveau d'abstraction égal, les performances sont totalement différentes, y a vraiment un problème :-))
[^] # Re: Benchmark J2EE vs dotNET
Posté par Stéphane Traumat (site web personnel) . Évalué à 1.
http://about.me/straumat
[^] # Re: Benchmark J2EE vs dotNET
Posté par Guillaume Carre . Évalué à 1.
[^] # Re: Benchmark J2EE vs dotNET
Posté par Gruik Man . Évalué à 1.
Nan.
ASM r0x0r :)
[^] # Re: Benchmark J2EE vs dotNET
Posté par Loic Jaquemet . Évalué à 1.
Ca vous choquerait vraiment ? si les performances étaient si importantes, on programmait tous en C et on ne ferait pas d'objet !
,</troll>
En faisant ca en C, ASM , fortan , cobol, tu changes de niveau d'abstraction.
Tu change donc tout ce qui concerne l'analyse, les processus d'implementation, probablement l'architecture logicielle, et surtout ce qui concerne le maintien de l'application a long terme ( OO , framework, evolutivite, reprise du code .. ) .
De ce que j'en sais , .NET et J2EE ca reste de l'oriente objet, avec un gros framework derriere .
Ce qui me 'choque', c'est que pour une meme abstraction, une meme approche d'implementation, les performances soient si differentes ...
Bon a la relecture des commentaires ici et la, j'en conclue que de toute facon , et fait dire ce qu'on veut a un Benchmark qui compare framework nativement different .
PS: genre les performances ca interesse personne ....
[^] # Re: Benchmark J2EE vs dotNET
Posté par Stéphane Traumat (site web personnel) . Évalué à 1.
http://about.me/straumat
# Re: Benchmark J2EE vs dotNET
Posté par Gilles Mocellin . Évalué à 1.
on peut multiplier le nombre de serveurs, avec seulement les coûts hardware.
(Evidement, si on a weblogic, faudra le payer aussi)
On le dit pas encore assez, mais le clustering, c'est un grand débouché pour les systèmes libres.
J'aurais bien aimé voir un bench avec un cluster de 10 PC, avec JBoss...
[^] # Re: Benchmark J2EE vs dotNET
Posté par pasBill pasGates . Évalué à 1.
Les couts de licence representent pas grand-chose dans le total d'habitude.
[^] # Re: Benchmark J2EE vs dotNET
Posté par patton . Évalué à 1.
[^] # Re: Benchmark J2EE vs dotNET
Posté par pasBill pasGates . Évalué à 1.
Pour du calcul scientifique ou des fermes de site web, effectivement la maintenance represente moins vu que c'est quasiment des systemes repliques.
[^] # Re: Benchmark J2EE vs dotNET
Posté par Olivier Jeannet . Évalué à 1.
(note: konsole est le xterm de KDE en gros)
C'est génial ce truc, j'avais jamais vu !
Bon je ne sais pas si je m'en servirai bientôt mais faut avoir eu l'idée quand même...
Quelqu'un s'en sert ici ?
[^] # Re: Benchmark J2EE vs dotNET
Posté par ufoot (site web personnel) . Évalué à 1.
Ben voyons, si c'est si peu cher que ça, z'ont qu'a les offfrir les licenses 8-)
[^] # Re: Benchmark J2EE vs dotNET
Posté par pasBill pasGates . Évalué à 1.
[^] # Re: Benchmark J2EE vs dotNET
Posté par Annah C. Hue (site web personnel) . Évalué à 1.
Merci de m'envoyer un chèque correspondant à 1% de votre budget informatique, car ça fait pas grand chose au final, 10 000, c'est rien comparé à 1 000 000.
En plus pour le prix je peux vous faire une facture. Et un an de garantie. Et les mises à jour gratuites. Et le support aussi.
[^] # Re: Benchmark J2EE vs dotNET
Posté par Stéphane Traumat (site web personnel) . Évalué à 1.
http://about.me/straumat
[^] # Re: Benchmark J2EE vs dotNET
Posté par Guillaume Laurent (site web personnel) . Évalué à 1.
pbpg a raison, les licenses sont une goutte d'eau dans le budget d'un projet de dev moyen.
[^] # Re: Benchmark J2EE vs dotNET
Posté par Stéphane Traumat (site web personnel) . Évalué à 1.
http://about.me/straumat
[^] # Re: Benchmark J2EE vs dotNET
Posté par Guillaume Laurent (site web personnel) . Évalué à 1.
C'est pourtant pas compliqué à comprendre : ce qui coute vraiment cher c'est pas le matos et les licenses soft, c'est le temps et les employés.
[^] # Re: Benchmark J2EE vs dotNET
Posté par vrm (site web personnel) . Évalué à 1.
ca commence a faire
# Re: Benchmark J2EE vs dotNET
Posté par Bouiaw . Évalué à 1.
Un minimum d'impartialité peut pas faire de mal ...
[^] # Re: Benchmark J2EE vs dotNET
Posté par Stéphane Traumat (site web personnel) . Évalué à 1.
Mais bon sang, si le fait que .Net soit plus performant soit un danger pour Java, alors, n'ayez pas peur de .Net, ayez peur des scripts CGI et de l'assembleur...
Faut bosser pour améliorer les performances mais bon, je ne pense pas que beaucoup de boites choisissent J2EE pour ces performances.
A+
TrOm
http://about.me/straumat
[^] # Re: Benchmark J2EE vs dotNET
Posté par Moby-Dik . Évalué à 1.
Depuis quand Java est un étendard du logiciel libre ? Java est libre ? Spécifications complètes, standardisées ? C'est le langage majoritaire dans les logiciels libres ou sous Linux peut-être ? C'est le langage universel dont tout le monde rêvait ? (des tas de gens bien détestent Java)
Sun peut essayer de "revenir dans la course" si ça l'amuse, mais pourquoi devrait-on l'aider à cela ?
[^] # Re: Benchmark J2EE vs dotNET
Posté par Stéphane Traumat (site web personnel) . Évalué à 1.
Il existe des outils Open source en java pour faire du java :
Apache tomcat, cocoon, eclipse, forte, jonas....
Donc, pour résumer :
- C'est gratuit
- C'est facile
- Ca évolue vite et c'est pas SUN qui décide tout seul
- Il y a des outils open source
- Il y a des serveurs open source
- Il est très répandu
Si j'ai bien lu, tout ce que tu lui reproches, c'est que les spécifications ne soient pas open source... si c'est le seul argument que tu as, présente nous un langage sur lequel on pourra faire autant de compliments et moins de reproche (c'est à dire 0)
a+
TrOm
http://about.me/straumat
[^] # Re: Benchmark J2EE vs dotNET
Posté par Moby-Dik . Évalué à 1.
Après tout :
- .Net a le même genre de propriétés que Java (abstraction, portabilité)
- .Net est de plus en phase de normalisation (contrairement à Java dont les specs et l'évolution sont sous contrôle absolu d'une entreprise unique)
- .Net est de plus attaquable depuis des tas de langages différents (contrairement à Java où le langage est lié à la plateforme)
- Java a des problèmes de portabilité d'une JVM à l'autre (pas besoin d'essayer de minimiser le problème, c'est patent)
Au fait, super le JDK de Sun "gratuit"... Je te rappelle que free speech != free beer. Par contre, Mono, lui, est libre et gratuit (même si pas encore fini).
La question finale reste donc : qu'est-ce que cet attachement à Java a à voir avec le logiciel libre (sous-entendu par le post initial) ?
[^] # Re: Benchmark J2EE vs dotNET
Posté par kruskal . Évalué à 1.
il y a un probleme de choix pas évident
D'un coté, java, non normalisé, de l'autre .net, normalisé et ouvert, mais provenant de l'empire lui meme.
Des deux cotés, des implémentations libres pas encore au point (gcj/orb/mono/dotgnu)
Alors, que choisir ?
Pour ma part, c'est tout choisi, Ocaml roulaize
[^] # Re: Benchmark J2EE vs dotNET
Posté par boubou (site web personnel) . Évalué à 1.
[^] # Re: Benchmark J2EE vs dotNET
Posté par Stéphane Traumat (site web personnel) . Évalué à 1.
Pour la portabilité, j'attends de voir...
Quand à la specification, elle n'est pas sous l'unique controle de SUN étant donné qu'il y a JCP
C'est vrai par contre que .net est attaquable par pleins de langages en théorie mais à part C#, ASP.net et VB.net... faudra me montrer des exemples...
Je minimise le problème d'une JVM à un autre car c'est pour moi un problème TRES TRES rare et que la perfection n'est pas de ce monde.
Etant donné le nombre considérable de produits libres existants pour Java (Tomcat, JBoss, Jonas Forte, Struts, Cocoon, SAX....) et que .net se base essentiellement sur des architectures non libres (.Net Serveur, IIS, SQL Server, Visual studio...), je pense que cela a un rapport...
Tu dis toi même que le langage n'est pas un problème alors regarde plutot la liberté de choix et d'ouverture qu'offre Java par rapport à .NET...
http://about.me/straumat
[^] # Re: Benchmark J2EE vs dotNET
Posté par kruskal . Évalué à 1.
Je concede que le probleme est le meme actuellement avec .net
[^] # Re: Benchmark J2EE vs dotNET
Posté par chrtela . Évalué à 1.
D'autre part, il ne sera peut-être bientôt plus nécessaire de disposer d'une JVM, grâce à gcj.
Enfin, pour répondre à un post plus haut, il me semble que certains langages peuvent être compilés en ByteCode (notamment Jython, crois-je). La plate-forme J2EE ne sera pas toujours mono langage.
[^] # Re: Benchmark J2EE vs dotNET
Posté par chrtela . Évalué à 1.
A partir de là, il me semble que oui, le fait que Java se fasse torcher par .Net pourrait être un problème pour la communauté.
Genre plein de projets développés sur une plate-forme devenant moribonde, ça serait quand même du gâchis. Et moi, le gâchis, je trouve pas ça très positif.
Sinon, la JVM fait tourner du ByteCode. Rien n'empêche de développer un nouveau langage qui se compile en ByteCode, et d'ailleurs ça existe déjà (Jython).
Si il n'y a pas plus de langages sur la plate-forme J2EE, c'est à mon avis parce que cela ne présente pas beaucoup d'intérêt. Pas plus que sur .Net d'ailleurs. Faire du VB.Net ou du C# n'est pas à proprement parler une alternative technique, tout au mieux un choix esthétique de seconde importance. C'est pas parce que t'as fait du VB que tu vas pondre du code objet propre en VB.Net...
Enfin, tes problèmes de portabilité, je veux bien croire qu'il y en a, mais je n'en ai jamais souffert. Pas besoin de les minimiser : ils sont effectivement minimes.
[^] # Re: Benchmark J2EE vs dotNET
Posté par Moby-Dik . Évalué à 1.
Certes ce serait un gros gâchis. Mais le gâchis est assez directement lié au fait d'avoir choisi un langage et des bibliothèques propriétaires. En gros, les gens qui ont utilisé Java pour des projets open-source ont construit leur propre cage.
Sinon, la JVM fait tourner du ByteCode. Rien n'empêche de développer un nouveau langage qui se compile en ByteCode,
S'il s'agit simplement de choisir un bytecode, il y a plein d'alternatives à Java. D'après Mono (qui ne sont peut-être pas très objectifs, mais bon), le bytecode .Net est plus performant car mieux adapté à la compilation JIT. Les auteurs de Parrot (la future VM de Perl) ont l'air assez enthousiastes vis-à-vis des performances qu'ils obtiennent. Etc.
Note : s'il y a plusieurs projets (Mono, dotGnu) qui s'occupent de recréer un environnement de développement et d'exécution .Net complet en opensource, alors qu'il n'y en a pas en Java, c'est peut-être qu'il y a une raison.
C'est pas parce que t'as fait du VB que tu vas pondre du code objet propre en VB.Net...
Non, mais pouvoir choisir le langage approprié pour une appli est important. On ne fait pas facilement des petits scripts en Java, ni du calcul scientifique.
Ah oui, et disclaimer : je suis loin d'être un fan de .Net et de ce genre de modes technologiques soudaines.
[^] # Re: Benchmark J2EE vs dotNET
Posté par Yusei (Mastodon) . Évalué à 1.
GCJ, GNU Classpath, Kaffe... D'accord ils ne sont peut être pas tous super en forme, mais ils existent. Je ne suis pas persuadé qu'actuellement Mono soit tellement plus complet, par exemple...
[^] # Re: Benchmark J2EE vs dotNET
Posté par chrtela . Évalué à 1.
Mouais, mais mon exemple était hypothétique. Une fois encore, il existe des alternatives aux solutions Sun (la JVM blackdown d'IBM sur Linux par exemple). Je voulais surtout te montrer que non, la communauté libre n'était pas totalement déconnectée du combat .Net/J2EE.
Pour le paragraphe sur le ByteCode, je suis tout à fait d'accord. Il y a plein d'alternatives à Java. Tu en conclues quoi ? Moi, je n'en conclus rien du tout.
Non, mais pouvoir choisir le langage approprié pour une appli est important. On ne fait pas facilement des petits scripts en Java, ni du calcul scientifique.
Qu'on me corrige si je me trompe, mais .Net et J2EE ont tous les 2 une orientation fortement business. Je ne ferais pas du calcul scientifique, ni avec l'un, ni avec l'autre. Pas plus que je ne m'en servirais pour faire des scripts.
Je crois plutôt que la volonté de Microsoft de fournir plusieurs langages tient à permettre une migration plus facile des développeurs quel que soit leur horizon. Piocher large, quitte à laisser les gens continuer à coder n'importe comment, en somme.
Enfin, je ne suis pas moi non plus fan des "modes technologiques", mais Java est maintenant bien implanté en entreprise et y restera encore longtemps vu l'ampleur des projets. D'ailleurs, je ne doute pas une seule seconde que .Net atteindra des chiffres de vente conséquents. Pourquoi est-ce important ? Réponse au début de mon post initial.
[^] # Re: Benchmark J2EE vs dotNET
Posté par boubou (site web personnel) . Évalué à 1.
[^] # Re: Benchmark J2EE vs dotNET
Posté par tene . Évalué à 1.
Mais la machine virtuelle n'a pas été conçue pour supporter plein de langage, c'est plus un effet de bord... techiquement, tu pourrais produire du bytecode java depuis n'importe quel langage, pratiquement certains produiront de bien meilleurs résultats...
Si il n'y a pas plus de langages sur la plate-forme J2EE, c'est à mon avis parce que cela ne présente pas beaucoup d'intérêt. Pas plus que sur .Net d'ailleurs. Faire du VB.Net ou du C# n'est pas à proprement parler une alternative technique, tout au mieux un choix esthétique de seconde importance. C'est pas parce que t'as fait du VB que tu vas pondre du code objet propre en VB.Net...
D'accord avec toi... mais l'intêret réside surtout dans le fait de pouvoir utiliser un composant développer en n'importe quel langage avec n'importe quel langage, et que le tout soit correctement supporté (pas de lourd coût de marshalling, comme on le connait sous Win32 avec les ActiveX, debugging facile entre langage, etc...). Prendre VB et C# n'est à mon avis pas l'idéal... prends plutôt C++ et C#... un "nouvel arrivant" va utiliser C# plus "facile" syntaxiquement... un autre gardera C++... le tout restera cohérent et en principe performant.
Enfin, tes problèmes de portabilité, je veux bien croire qu'il y en a, mais je n'en ai jamais souffert. Pas besoin de les minimiser : ils sont effectivement minimes.
Euh, j'ai du faire une app java linux/windows (pas trop de problème) et ... macosx (avec la jvm de webobject) et là... boum! plein de petits détails... un autre problème aussi: les différences d'une jvm à l'autre... tomcat se ramassse la gueule avec la 1.4 avec la 1.3 ça passe très bien... un bête code de drag and drop ne donne pas le même résultat selon l'os.... etc... En bref, ça existe bel et bien... et comme c'est toujours le cas pour ce genre de problème: ils ne sont pas minimes si tu les subits, et ils sont inexistant si tu n'en es pas la victime.
[^] # Re: Benchmark J2EE vs dotNET
Posté par chrtela . Évalué à 1.
C'est clair que Java pour faire de la GUI, j'évite autant que possible. L'interaction avec le bureau Windows, les communications OLE Automation avec MS/Office, c'est trop galère. A chaque fois, passage obligé par JNI.
Je suis bien certain que .Net sera bien meilleur pour ça, mais quoi d'étonnant... Enfin, ça ne peut aller qu'en s'améliorant du côté Java, et les solutions mises en oeuvre par IBM (pour Eclipse, ils ont utilisé un tookit GUI maison vraiment performant) sont pleines de promesses a priori tenues.
Sinon, pour les autres points :
Mais la machine virtuelle n'a pas été conçue pour supporter plein de langage
Oui, mais on s'en fout ! Et le fait que Microsoft permette à un développeur VB de passer à VB.Net pour faire du .Net me paraît plutôt une faiblesse. J'imagine le code que les programmeurs vont sortir. Déjà que beaucoup de programmeurs VB n'ont pas encore assimilé la notion de classe, et continuent à faire de l'évènementiel.
[^] # Re: Benchmark J2EE vs dotNET
Posté par phil0fr . Évalué à 1.
>le code que les programmeurs vont sortir. Déjà que beaucoup de programmeurs VB n'ont pas encore assimilé la notion de classe, et continuent à faire de l'évènementiel.
Rapport entre class et événementiel ?
[^] # Re: Benchmark J2EE vs dotNET
Posté par Guillaume Laurent (site web personnel) . Évalué à 1.
[^] # Re: Benchmark J2EE vs dotNET
Posté par phil0fr . Évalué à 1.
[^] # Re: Benchmark J2EE vs dotNET
Posté par Dawm . Évalué à 1.
[^] # Re: Benchmark J2EE vs dotNET
Posté par Yusei (Mastodon) . Évalué à 1.
.Net est une plateforme, comme la plateforme Java (différente du langage Java). Il est possible de compiler différents langage pour .Net comme pour la plateforme Java. Quant au problème de portabilité entre JVM, ça ne m'a pas encore choqué, bien que j'aie pas mal développé en Java, mais je veux bien te croire. C'est difficile de comparer les plateformes .Net pour l'instant, cependant ;-)
«Mono, lui, est libre et gratuit (même si pas encore fini).»
Si on raisonne comme ça, il existe plusieurs projets de JVM et/ou compilateurs Java libres, mais pas finis :-)
Sinon pour le reste rien à redire, pour l'instant Java n'est pas une option si on veut vraiment faire du libre sur plateforme libre.
[^] # Re: Benchmark J2EE vs dotNET
Posté par Bouiaw . Évalué à 1.
PS Il n'ont pas le choix, si ils veulent que java survive ...
[^] # Re: Benchmark J2EE vs dotNET
Posté par kruskal . Évalué à 1.
IBM veut pousser Sun a liberer les Jvm.
C'est une excellente chose, et j'espere que c'est vrai \o/
[^] # Re: Benchmark J2EE vs dotNET
Posté par kruskal . Évalué à 1.
http://techupdate.zdnet.com/techupdate/stories/main/0,14179,2879892(...)
[^] # Re: Benchmark J2EE vs dotNET
Posté par Brice Carpentier . Évalué à 1.
ils ont pensés aux nains de jardins ?
bon, ok, je sors, désolé mais ct tentant.
# J2EE, dotNET, ... et y'en a pas d'autre ?
Posté par Jiba (site web personnel) . Évalué à 1.
Ben pour moi ce sera Python, désolé !!!
Jiba
[^] # Re: J2EE, dotNET, ... et y'en a pas d'autre ?
Posté par Gabriel . Évalué à 1.
# Re: Benchmark J2EE vs dotNET
Posté par CMO (site web personnel) . Évalué à 1.
La license Microsoft interdit de publier un benchmark non favorable a .net ;
Donc maintenant, il suffit de refaire un benchmark "MonAppli" et la comparer avec celle de "TMC" pour montrer comment .net est lent.
Car Java est plus rapide que .net. Peut-etre pas nativement si on compare un parcourt de tableau ou des multiplications, par contre sur une application complete avec 500.000 lignes de code, java sera plus rapide (existe t'il deja des applications doNot avec autant de code ?)
Pour une application avec 10.000.000 de lignes de code, java sera plus rapide que du C, du C++ ou du Fortran.
Experience personnelle, je bosse sur une application java / fortran developpe depuis 2 ans par 40 personnes... la premiere version est prevue en debut d'annee prochaine (dans les delais). C'est un systeme de data processing fait pour tourner sur des clusters jusqu'a 4000 CPU.
[^] # Re: Benchmark J2EE vs dotNET
Posté par pasBill pasGates . Évalué à 1.
C'est marrant, tu ne sais pas si il existe des applis .net avec autant de lignes de code, mais par contre tu sais deja que Java sera plus rapide.
Pour une application avec 10.000.000 de lignes de code, java sera plus rapide que du C, du C++ ou du Fortran.
C'est bien connu, d'ailleurs on est en train de reecrire Windows XP en Java. On a ete abasourdi par les perfs de Corel Office, et on s'est dit qu'on pouvait pas faire pire de toute facon.
[^] # Re: Benchmark J2EE vs dotNET
Posté par Nelis (site web personnel) . Évalué à 1.
Vivement que les XPs reviennent ...
[^] # Re: Benchmark J2EE vs dotNET
Posté par pasBill pasGates . Évalué à 1.
[^] # Re: Benchmark J2EE vs dotNET
Posté par Nelis (site web personnel) . Évalué à 1.
C'est bien connu, d'ailleurs on est en train de reecrire Windows XP en Java. On a ete abasourdi par les perfs de Corel Office, et on s'est dit qu'on pouvait pas faire pire de toute facon.
Windows XP et Corel Office n'ont RIEN A VOIR avec J2EE mais seraient plutôt écrit avec J2SE, d'où ta remarque est complètement hors-propos. Et toi tu te ramènes avec ce post dont je ne comprends pas du tout le sens :-)
Dis, vous avez des formations pour le FUD et la mauvaise foi chez MS ?
[^] # Re: Benchmark J2EE vs dotNET
Posté par pasBill pasGates . Évalué à 1.
Je cites du 1er post:
Car Java est plus rapide que .net.
C'est moi qui ait dit ca ?
Bon, alors va donner tes lecons de FUD et de mauvaise foi ailleurs mon cher.
[^] # Re: Benchmark J2EE vs dotNET
Posté par Guillaume Laurent (site web personnel) . Évalué à 1.
C'est marrant, à chaque fois que pbpg dis un truc, tout à fait sensé et raisonnable (mais ça vous pouvez pas supporter), il y en a toujours un pour sodomiser les drosophiles et lui dire "t'es hors sujet, nananèreuuuh". Mais jamais une réponse sur le fond.
Et pour cause, non seulement il dit des trucs vrais la plupart du temps, mais son niveau technique est bien au dessus de la moyenne ici.
Si tu veux aider le libre, commence par te comporter autrement que comme un fan de Britney Spears à qui on essaie d'expliquer que c'est pas la plus grande chanteuse du siècle.
Essaie ça : demande à quelqu'un d'extérieur à la discussion de lire tes posts sur ce thread, et demande-lui son avis, objectivement. De préférence quelqu'un qui a fini sa puberté, et pour qui les ordinateurs sont juste un outil de travail.
[^] # Re: Benchmark J2EE vs dotNET
Posté par MetalX . Évalué à 1.
(completement inutile mais bon)
[^] # Re: Benchmark J2EE vs dotNET
Posté par Guillaume Laurent (site web personnel) . Évalué à 1.
Non, pas complètement, ça fait toujours plaisir :-).
[^] # Re: Benchmark J2EE vs dotNET
Posté par pasBill pasGates . Évalué à 1.
# Plein de langage pour la JVM
Posté par Pat . Évalué à 1.
http://grunge.cs.tu-berlin.de/~tolk/vmlanguages.html(...)
[^] # Re: Plein de langage pour la JVM
Posté par Moby-Dik . Évalué à 1.
- des interpréteurs Prolog écrits en Java (super)
- des outils de traduction C-vers-Java (très utile :-))
- des extensions de Java
...
Du reste, le problème c'est que Java n'a été *conçu* que pour un seul langage, ce qui veut dire que même si des passerelles sont programmées par des programmeurs tiers, ça risque fort d'être de la bidouille.
[^] # Re: Plein de langage pour la JVM
Posté par boubou (site web personnel) . Évalué à 1.
Il existe au moins deux langages très intéressants qui compilent pour la JVM, à savoir Python et Eiffel. Donc, bien sûr, le lien donné plus haut contient aussi des choses plus anecdotique, mais franchement entre VB sur .Net et Eiffel sur JVM, j'ai un petit faible pour la deuxième solution...
Sinon, effectivement la JVM a été pensée pour Java, mais la machine virtuelle .Net (CLR) a aussi été conçue avec certains biais. Par exemple le CLR a été conçu presque uniquement pour le JIT contrairement à la JVM. Sur le site http://www.citi.qut.edu.au/research/plas/projects/cp_files/Componen(...) il a d'ailleurs une comparaison assez claire des deux architectures. On constate par exemple que la vérification de code pour CLR demande nécessairement une partie runtime, ce qui n'est pas le cas pour la JVM (d'où une perte de performance pour le premier). Par contre CLR autorise le passage de paramètre par adresse pour les types fondamentaux, ce qui permet une implantation efficace des langages qui autorisent ce genre de construction, contrairement à la JVM. Un autre aspect est que l'interprétation (sans JIT) du code CLR est souvent plus lent que pour la JVM, toujours pour des raisons d'architecture.
Bref, CLR a été effectivement pensé pour supporter divers langages, mais en pratique il y a une seule différence majeure avec la JVM : la possibilité d'implanter efficacement le passage par référence des types fondamentaux. Franchement, on ne va pas en faire tout un fromage...
[^] # Re: Plein de langage pour la JVM
Posté par pacman . Évalué à 1.
[^] # Re: Plein de langage pour la JVM
Posté par Moby-Dik . Évalué à 1.
:-))
Apparemment les développeurs Mono considèrent que le bytecode .Net est mieux adapté à une optimisation en JIT que le bytecode Java. Certes ce sont les développeurs Mono, mais ils n'ont pas d'intérêt commercial dans .Net, et ils ont choisi librement de traiter le sujet .Net alors qu'ils auraient pu prendre Java, ce qui ne remet pas en cause leur indépendance.
L'autre problème est que la possibilité de bindings dans plein de langages est activement supportée par MS (argument de vente de .Net) tandis que je n'ai pas l'impression que Sun fasse beaucoup de pub autour de la même chose pour Java, et s'en soucie. En clair, si un jour Sun veut sortir un machin qui ne sera efficacement implémentable qu'avec le _langage_ Java, a priori ils ne s'en priveront pas.
# Commentaires sur jGuru
Posté par Etienne Juliot (site web personnel) . Évalué à 1.
http://dreambean.com/petstore.html(...)
Par exemple :
"Several independent sources have now confirmed that The Middleware Company was indeed paid by Microsoft to conduct this report."
ou
"It should be noted that the J2EE PetStore used in this benchmark report is based on Suns Java Pet Store 1.1.2, which is over two years old. The most recent version (1.3.1) uses CMP, local interfaces, and caching. If the J2EE PetStore used in this report is supposedly "fully optimized for performance", why was it based on a very old version of the PetStore?"
[^] # Re: Commentaires sur jGuru
Posté par pasBill pasGates . Évalué à 1.
[^] # Re: Commentaires sur jGuru
Posté par Nelis (site web personnel) . Évalué à 1.
[^] # Re: Commentaires sur jGuru
Posté par pasBill pasGates . Évalué à 1.
# Re: Benchmark J2EE vs dotNET
Posté par Cook Captain . Évalué à 1.
N'importe quel imbécile est capable de vous pondre un bench ou le système "panpan" va 1000x plus vite que le système "peper". Suffit de changer 3 lignes de code et le tour est joué.
Pour M$, le bench truqué (au même titre que le FUD) , c'est uniquement une technique de marketing. Seuls qq boutonneux ont décèlé (après coup) le coté véreux du bench - les décideurs n'ont évidemment rien vu - le mal est fait...
# Re: Benchmark J2EE vs dotNET
Posté par Pierre Tramo . Évalué à 1.
[^] # Re: Benchmark J2EE vs dotNET
Posté par Olivier Jeannet . Évalué à 1.
Tu as raison, j'avais pas fait gaffe (j'ai l'ADSL aussi) ! C'est dingue, ils laissent tous les commentaires sur la même page, il n'y a même pas de limiteur ou de pointeur "suivant" (style "20 commentaires suivants")
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.