[Débat] Technologie .NET vs JAVA

[LLB]

Envoyé par Tarul

Pour les entreprises possédant des serveurs ou des postes de travail linux (unix?), je dirais que cela peut être un gros problème. Elles n'ont pas une garantie proche de 100% que leur applicatif va fonctionner aussi bien sous linux/mono que sous windows/mono.

Mono est portable, on peut développer avec Mono sous Windows et j'imagine qu'il n'y a pas beaucoup de différence avec la version Mono sous Unix. À moins d'écrire en dur "c:\windows\.." dans le code ou d'utiliser une API spécifique à Windows.

Par ailleurs, il existe un outil qui permet de tester un fichier binaire et qui indique s'il utilise des fonctions non implémentées dans Mono.

Dans le cas présent, le problème n'est pas de savoir si mono est en avance sur les concurrents de la plateforme .Net mais bel et bien par rapport à l'implémentation "officielle" de microsoft.

Non, quand on commence un développement, on compare les différentes options que l'on a. On peut se demander s'il vaut mieux développer en Java, ou .NET ou utiliser un autre langage. Dès lors que l'on a choisi .NET et que l'on souhaite une portabilité Unix, il n'y a pas beaucoup d'autre choix que Mono. On fait donc avec.

Mais cette portabilité n'est pas la même, ici il s'agit de portabilité des langages sur la plateforme DotNet, non et la portabilité de la plateforme elle-même?

Il s'agit de logiciels écrits pour .NET. C'est du bytecode .NET écrit sous Windows qui est exécuté avec Mono sous Unix. Cela prouve bien que le bytecode est portable, même quand c'est développé par Microsoft. Cela prouve que les logiciels conçus sous Windows pour MS .NET sont portables (quand on ne fait pas n'importe quoi). F# étant un compilateur, on remarque aussi que le code généré par F# s'exécute aussi bien sous Mono. Il n'y a donc pas grand-chose à reprocher à Mono.

Quant à la portabilité de Mono lui même : http://www.mono-project.com/Supported_Platforms

Je serais curieux de te voir argumenter cela !

C'est presque le même débat que MS .NET / Java, à quelques détails près.

On peut commencer par l'implémentation des generics, la récursivité terminale, et continuer avec les langages disponibles (C# Linq inclus, F#, IronPython, IronRuby, Phalanger (PHP), VB 8). Il y a d'autres langages sur le site de Mono, mais je ne sais pas ce qu'ils valent (Scala, Boo, Eiffel, Java...). Je me suis déjà amusé à utiliser Mono comme une bibliothèque. Mon code C natif (compilé avec gcc) pouvait appeler des fonctions écrites en PHP et le PHP pouvait appeler mes fonctions C natives. Je ne sais pas si des implémentations de Java permettent ça. À part Java et Fortress, quels langages pour la JVM sont mûrs et développés par une entreprise fiable et pérenne ?

[joho]

Envoyé par Jabbal'H

Je mettrais un point en plus à Java pour la techno JNLP (java web start) juste parce que cà simplifie énormément le déploiement. Apres je ne crois pas qu'il éxiste d'équivalent en DotNet.

Click Once est (je pense) un équivalent à JNLP.
http://morpheus.developpez.com/clickonce/

[gorgonite]

Envoyé par LLB

À part Java et Fortress, quels langages pour la JVM sont mûrs et développés par une entreprise fiable et pérenne ?

Scala, Groovy, JRuby... au minimum, même si j'ai un a priori sur l'utilisation que fait Sun de JRuby et Jython

[kisitomomotene]

Envoyé par _skip

J'utilise actuellement vs2008 et le framework devexpress, je paie environ 1500 euros par année pour cela.
Mais je met quiconque au défi de trouver un équivalent en java, ce n'est possible ni sur le plan de la qualité de l'expérience end-user (GUI riche, interface customisable),.

Jette un coup d'oeil à Ext Gwt

[sinok]

Envoyé par LLB

À part Java et Fortress, quels langages pour la JVM sont mûrs et développés par une entreprise fiable et pérenne ?

On peut aussi ajouter Cal (et le framework Open Quark) qui est développé par Business Objects (ça devrait pouvoir passer comme entreprise pérenne non? )

[gorgonite]

Envoyé par sinok

Business Objects (ça devrait pouvoir passer comme entreprise pérenne non? )

ce n'est pas parce qu'une entreprise est pérenne, que le produit a de l'avenir

[jahbromo]

Jusqu'a present et dans le futur on peut pas comparer Java et .Net.

Java n'est pas un langage comme les autres : Sa portabilité et sa gratuité et sa puissance fait de lui le langage le plus utilié.
Microsoft etant par definition fermée.
Une mise en garde : Si vous utilisez .Net, et que vous dependrez de lui, alors cela sera une autre colonisation

[hcrepin]

Cela dit, par expérience, je trouve que JAVA est très gourmand en ressources, on dirait que plus ça avance, plus c'est comme Microsoft, les serveurs sont plus puissants mais on met pas plus dessus parce que le développement est beaucoup plus gourmand.

Actuellement, on met des mémoire entre 1 Gb et 4 Gb par JVM sous JAVA pour des fonctions qui tournaient en 32 ou 64 Mbytes avant.

En .NET, je suppose que c'est la même farandole?

[nicorama]

Envoyé par hcrepin

Cela dit, par expérience, je trouve que JAVA est très gourmand en ressources

C'est plutôt l'inverse , les performances sont toujours meilleures. Maintenant, c'est sûr qu'avec l'expérience, on est plus tenté à utiliser de plus en pus de modules qui sont proposés par Java.

[le y@m's]

Envoyé par hcrepin

Actuellement, on met des mémoire entre 1 Gb et 4 Gb par JVM sous JAVA pour des fonctions qui tournaient en 32 ou 64 Mbytes avant.

jamais vu ça, d'où sors tu une information aussi extravagante ?
Comme l'a dit nicorama les performances des JVMs n'ont fait que s'améliorer après chaque version.

[Bluedeep]

Envoyé par jahbromo

Jusqu'a present et dans le futur on peut pas comparer Java et .Net.

Affirmation bien hasardeuse; sur quoi repose-t-elle ?

Java n'est pas un langage comme les autres : Sa portabilité et sa gratuité et sa puissance fait de lui le langage le plus utilié.

Sources ?

Microsoft etant par definition fermée.

Quel rapport avec le reste ?

Une mise en garde : Si vous utilisez .Net, et que vous dependrez de lui, alors cela sera une autre colonisation

Pur portnawak.

A part ça, sur la couleur des ordis, t'as une opinion ?

[_skip]

Actuellement, je pense que la vitesse est satisfaisante autant en java qu'en .net. Surtout qu'il existe toujours les solutions de compilation en native pour ceux qui détestent le JIT.

[gouessej]

Envoyé par _skip

Actuellement, je pense que la vitesse est satisfaisante autant en java qu'en .net. Surtout qu'il existe toujours les solutions de compilation en native pour ceux qui détestent le JIT.

Il y a aussi des solutions AOT comme Excelsior Jet bien que ça ne soit pas très portable

Envoyé par hcrepin

Actuellement, on met des mémoire entre 1 Gb et 4 Gb par JVM sous JAVA pour des fonctions qui tournaient en 32 ou 64 Mbytes avant.

C'est exactement l'inverse. Plus le temps passe, plus les ramasse-miettes sont performants et plus particulièrement le G1. Pourrais-tu donner tes sources?

[_skip]

Il y a aussi des solutions AOT comme Excelsior Jet bien que ça ne soit pas très portable

Oui c'est à ça précisément que je pensais.

[Franck SORIANO]

Envoyé par _skip

Actuellement, je pense que la vitesse est satisfaisante autant en java qu'en .net.

Quand on est sur une application serveur, la vitesse ne veut pas dire grand chose. Si un traitement se calcule en 10 ms alors qu'il pourrait être calculé en 1 ms avec une autre solution, on peut avoir envi de dire : 10 ms ou 1 ms ça n'a pas d'importance, dans tous les cas c'est satisfaisant puisque ce n'est pas perceptible par l'utilisateur.

Sauf que dès que le serveur commence à monter en charge, 10 ms c'est 10 fois plus que 1 ms, donc le serveur supportera 10 fois moins d'utilisateurs...

Sans même aller jusqu'à atteindre la saturation, si un traitement consomme d'avantage de ressources, la probabilité que les ressources ne soient pas disponibles au moment où le client envoie la requête augmente d'autant. Donc la probabilité que la requête soit mise en attente avant d'être traitée augmente également.
Si la requête est mise en attente, les temps de réponses preinent une claque en relation avec la longueur de la file d'attente à ce moment là.

Autrement dit, 10 ms au lieu de 1 ms sur un temps de traitement unitaire ça peut donner des temps de réponse très fortement dégradés dès que le serveur commence à monter en charge...