Discussion :

[nicolofontana12]

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]

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]

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]

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.

[Invité]

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

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]

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

[hegros]

On ne peut pas le nier MS donne le beat et les autres s'adaptent et suivent bon gré ou mal gré.


Java s'est à l'époque de l'intermédiaire langage primaire avec le CLS* et sa fcl** MS a pris le large et les portages de DOTNET (pour les puristes de la portabilité) ne sont pas vraiment un problème bientôt on verra venir un JAVA.NET et des Linux.NET en tout cas des MS.JAVA ou des MS.Linux c'est confirmé pour non


*CLS c'est le common language specification traduisez spécification de langage commun c'est ce qui fait que vous pouvez faire du .NET avec C#, ASP, Visual Basic, Delphi, Php et bien d'autres encores.


**fcl c'est le framework classe library la bibliothèque que vous utilisez pour programmer c'est un paquet de classes logicielles partagé par les langages

[fr1man]

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 dans ce cas précis, je ne pense pas qu'il y ait un rapport de 1 à 10 dans les performances.

[_skip]

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

Sur le fond je suis d'accord mais toutefois on peut aussi avoir le cas ou la version "rapide" en mono-utilisateur devient rapidement catastrophique dans des situations de concurrence.

Pour le reste, une différence d'un facteur de 10 me semble difficile à atteindre sans une différence de conception majeure.
En fait pour moi, l'idée que tu émets est vraisemblablement plus un problème de l'ordre de la conception et de l'architecture que du *langage* utilisé.

Je veux dire par là que ce n'est pas le fait qu'une boucle while soit écrite en java ou en .net ou même en c++ qui jouera le plus grand rôle bien souvent. Dans un exemple serveur, ce sera sans doute plus volontiers des choses tels que l'utilisation de caches, la gestion d'une éventuelle BDD, la limitation des opérations IO coûteuses.... bref la conception.

[Franck SORIANO]

Sauf que dans ce cas précis, je ne pense pas qu'il y ait un rapport de 1 à 10 dans les performances.

Tu n'as pas compris le sens de ma remarque. _skip a dit que dans un cas comme dans l'autre, "la vitesse est satisfaisante".
Ce que je dis, c'est que sur un serveur, quel que soit le langage, on ne peut jamais dire que la vitesse est satisfaisante car ce qui nous importe, ce n'est pas de gagner 10 ms sur le temps de traitement d'une requête (surtout sur un serveur Web, les utilisateurs sont habitués à ce que le web soit lent), mais le nombre d'utilisateurs qu'on pourra mettre par serveur afin de limiter le nombre de serveur et ainsi les coûts d'exploitation.

Pour le reste, une différence d'un facteur de 10 me semble difficile à atteindre sans une différence de conception majeure.

Détrompes-toi. La plupart des développeurs aujourd'hui considèrent qu'on peut faire n'importe quoi car "vu la puissance des machines actuelles, les performances ne sont pas un problème". Ou encore : "Moi j'utilise tel framework, si les perfs sont mauvaises je n'y peux rien", "L'optimisation c'est le problème du responsable technique, moi le mien c'est de coder la fonctionnalité qu'on me demande". On peut faire la même avec les DBA et les requêtes SQL.

Le gaspillage de ressources dans les applications est phénoménale (d'ailleurs personne n'a remarqué que les machines sont de plus en plus rapides, alors que les performances des applis ne s'améliorent pas ?).

Lorsque je fourre mon nez dans une appli, il n'est pas rare que j'obtienne des gains d'un facteur 10 ou similaire. Dernièrement j'ai obtenu un facteur 5 en changeant 10 lignes de code. Et parfois même, on obtient des gains très importants, simplement en changeant un paramétrage.

En fait pour moi, l'idée que tu émets est vraisemblablement plus un problème de l'ordre de la conception et de l'architecture que du *langage* utilisé.

C'est avant tout un problème d'optimisation. Ca commence par ne pas coder n'importe comment. Puis évidemment, ça passe par une conception adaptée. Le langage intervient également, car il impose ses contraintes et détermine une bonne partie de la conception.

Et le point de départ de tout ça, c'est une question de prise de conscience et de volonté ! D'où ma réaction, lorsque je vois "la vitesse est satisfaisante" au sujet de langages qui servent principalement à coder des serveurs

[_skip]

Et le point de départ de tout ça, c'est une question de prise de conscience et de volonté ! D'où ma réaction, lorsque je vois "la vitesse est satisfaisante" au sujet de langages qui servent principalement à coder des serveurs

Je ne sais pas si mon post est apparu dans un contexte sujet à interprétation, ce que j'ai voulu dire c'est que la vitesse d'exécution de java ou de .net d'un point de vue strictement langage est satisfaisante.

Tu sais, on entend beaucoup de gens dire de ces langages managés qu'ils sont lents et lourds etc ... J'admets qu'ils sont peut être moins rapides dans certaines situations que du C++ mais cependant ils ne sont pas assez lents à mon goût pour justifier qu'on les écarte sans réfléchir au nom de vieux clichés à la con. Sauf peut être si on écrit des algo de compression, de implémentations de reed solomon ou autres brassages de matrices.

Le reste c'est du domaine de la conception, en java, comme en .Net, comme en c++ on peut leur faire avaler n'importe quoi aux machines. On peut faire des accès disques irréfléchis, charger inutilement des mo de données en mémoire, sortir le marteau pour écraser la mouche.

Donc oui, je pense que la vitesse de java et de .net est satisfaisante. Mais à aucun moment je n'ai dit qu'on pouvait tous mettre nos cerveaux sur off et gaspiller des ressources sans compter, la qualité de l'implémentation ne repose pas principalement, à mon sens, sur le langage utilisé, c'était ça mon propos.

[fr1man]

Tu n'as pas compris le sens de ma remarque. _skip a dit que dans un cas comme dans l'autre, "la vitesse est satisfaisante".
Ce que je dis, c'est que sur un serveur, quel que soit le langage, on ne peut jamais dire que la vitesse est satisfaisante car ce qui nous importe, ce n'est pas de gagner 10 ms sur le temps de traitement d'une requête (surtout sur un serveur Web, les utilisateurs sont habitués à ce que le web soit lent), mais le nombre d'utilisateurs qu'on pourra mettre par serveur afin de limiter le nombre de serveur et ainsi les coûts d'exploitation.

J'ai bien compris mais encore une fois le problème que tu cites n'est pas un problème de technologie mais un problème d'implémentation de la part du ou des développeurs voire un problème de conception.

[Franck SORIANO]

J'ai bien compris mais encore une fois le problème que tu cites n'est pas un problème de technologie mais un problème d'implémentation de la part du ou des développeurs voire un problème de conception.

C'est un problème de conception, de réalisation, mais aussi de technologie. Tu peux faire la meilleure conception et la meilleure réalisation du monde, il arrivera un moment tôt ou tard où tu seras limité par la technologie que tu emploies.
C'est un tout auquel il faut faire attention.

Maintenant c'est vrai que le choix du langage est lui même un choix de conception. Donc au final, on peut toujours dire que ce n'est qu'un problème de conception...

[fr1man]

En l'occurrence le débat est .NET versus JAVA.
Je ne suis pas expert en .NET, mais je ne pense pas qu'il y ait un énorme fossé entre les deux technologies qui fasse que tu te plantes complètement en choisissant l'une plutôt que l'autre.

[_skip]

Pour avoir fait pendant 3 ans du c# et maintenant depuis 7 mois du java, j'ai pas l'impression non plus.
Cependant c'est vrai que les libs et outils à disposition ne sont pas toujours les mêmes bien qu'il existe de nombreuses équivalences.

Ca empêche de toutes façons pas de se renseigner sur ce qui est disponible dans chacune de ces technos pour un projet précis. Par contre contrairement à ce que je pensais avant de programmer professionnellement en java, on ne saute pas de l'un à l'autre si facilement, il faut du temps pour trouver ses marques.

[nicorama]

A mon sens il y a plus d'intérêt à débattre des langages "Fortement typés" (java, .net) vs "Faiblement typés" (php, javascript).

Et depuis les progrès fulgurants des ide (propositions, refactoring) depuis 3-4 ans, ca me fait toujours mal de passer à un langage faiblement typé. J'ai tenté une appli de quelques milliers de lignes en javascript, et on ne m'y reprendra plus.

[_skip]

En effet, j'ai commencé à écrire une librairie en PHP à l'intention d'un client qui veut utiliser nos services depuis ce langage. Ben ça me rend fou car ça demande une volée de tests unitaires pour contrôler des erreurs que j'ai l'habitude de voir mises en évidence par simple compilation.

Mais pour en revenir à ce débat .Net vs Java, je pense que tout le monde est d'accord pour dire que si l'un était sur tous les points supérieur à l'autre, ils ne cohabiteraient pas...