Discussion :

[pseudocode]

houla. j'ai de plus en plus peur...

Si tu preferes avec une classe mutable, prenons StringBuffer...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
public class Test {

	public static void someMethod(StringBuffer sb) {
		sb = new StringBuffer("world !");
	}

	public static void main(String[] args) {
		StringBuffer sb = new StringBuffer("hello");
		someMethod(sb);
		System.out.println(sb);  // <-- que vaut sb d'après toi ?
	}
}

A mon avis tu confonds "reference d'un objet" et "passage par reference d'un argument". Dans l'exemple que tu as donné, tu as utilisé comme argument une "reference d' objet". Pour autant, ce qui est utilisé par la methode c'est la "valeur" de l'argument et non pas sa "reference".

Pour information, et afin de ne pas laisser trop d'erreur sur un site de developpement:

En Java, tous les arguments sont passés par valeur (preuve ici par java.sun.com)

En C#, par défaut, les arguments sont passés par valeur. On peut les passer par reference en utilisant explicitement le mot clé "out" ou "ref" (preuve ici par msdn2.microsoft.com)

[Médinoc]

Je n'ai jamais dit que la référence elle-même était passée par référence, j'ai dit que tous les types références (c'est-à-dire, toutes les classes en Java) étaient modifiables. Ce qui est vrai: Tout objet non-mutable peut être modifié par toute fonction qui possède une de ses références.

Peut-être n'as-tu pas compris l'expression "type référence", qui est une expression de .Net : Elle différencie les types valeur (notamment les types primitifs, comme int, float, enums, etc.) des types référence (Object, String, etc.).

Une des différences entre Java et .Net, c'est qu'en java, toutes les classes sont forcément des types références, seuls les types primitifs et les enums sont des types valeur.
Alors qu'en .Net, on peut avoir des types valeur complexes, comme DateTime.

Et donc, regarde à nouveau mon post précédent: UneClasseNonImmuable est un type référence non-immuable, et peut donc être allègrement modifié dans la fonction : Il est donc à la fois en entrée et en sortie, puisque la fonction modifie l'objet lui-même.

[pseudocode]

Je n'ai jamais dit que la référence elle-même était passée par référence, j'ai dit que tous les types références (c'est-à-dire, toutes les classes en Java) étaient modifiables. Ce qui est vrai: Tout objet non-mutable peut être modifié par toute fonction qui possède une de ses références.

Yep, on est d'accord. Encore une chance qu'on puisse appeler les methodes d'un objet en dehors de l'objet lui meme !

Peut-être n'as-tu pas compris l'expression "type référence", qui est une expression de .Net : Elle différencie les types valeur (notamment les types primitifs, comme int, float, enums, etc.) des types référence (Object, String, etc.).

Vi vi, je suis au courrant. C'est meme un peu, hum, "compliqué" quand on veut utiliser les methodes Copy ou Clone (Deep, Shallow). Mais c'est a peine plus simple en Java (enfin si, un peu quand meme)

Une des différences entre Java et .Net, c'est qu'en java, toutes les classes sont forcément des types références, seuls les types primitifs et les enums sont des types valeur.
Alors qu'en .Net, on peut avoir des types valeur complexes, comme DateTime.

Oui, c'est un gros avantage de .Net: int, double, ... sont des classes et non pas des "types" comme en Java. Le pendant coté Java sont les classes Integer, Double,... qui sont immuables

Et donc, regarde à nouveau mon post précédent: UneClasseNonImmuable est un type référence non-immuable, et peut donc être allègrement modifié dans la fonction : Il est donc à la fois en entrée et en sortie, puisque la fonction modifie l'objet lui-même.

Oui, bien sur. Quel interet d'avoir un langages ou les objets ne sont pas modifiables !?

Mais ce n'est pas pour autant qu'ils sont "entrée et/ou sortie". Je veux dire que la "valeur" de la reference n'est pas modifiable en Java. Je suis certain que si je passe une instance de l'objet "Toto" en parametre d'une methode, au retour de la methode j'aurais toujours la meme instance de l'objet "Toto" (meme si la methode a utilisé cet objet et a changé son état).

Je trouve dangereux cet heritage du langage C++ (le symbole &). C'est certe tres pratique mais c'est dangereux.

En java, le seul moyen de retourner une "nouvelle" valeur, c'est d'utiliser la variable de retour de la methode. Je trouve ca assez logique. Mais c'est vrai que c'est lourd quans tu veux retourner 2 "int". Soit tu retournes un tableau de int[], soit tu crées une nouvelle definition de classe/interface pour le retour

Apres c'est une question de "confiance". Je prefere sacrifier la puissance de C# au profit de la sécurité de Java.

[LLB]

- La finalité de JSE est d'utiliser UN seul langage (java) pour implémenter une application qui s'executera sur TOUS les OS.

- Le finalité de .Net est utiliser N'IMPORTE QUEL langage pour implémenter une application qui s'executera sur UN OS (windows).

Je ne suis pas d'accord. La finalité de .NET est d'être complètement portable. Ce n'est pas encore parfait, mais ça va dans ce sens. J'ai testé Mono et j'ai été très agréablement surpris. Je n'ai pas suffisamment testé pour voir ses limitations, mais j'en ai vu assez pour savoir que c'est utilisable.

J'ai récemment écrit un compilateur entier, qui tourne sous .NET et qui génère du code pour .NET. J'ai développé uniquement sous Windows, sans jamais me poser la moindre question de portabilité. Il y a quelques semaines, j'ai essayé sous Linux. Hé bien, mon compilateur tourne parfaitement et le code généré tourne aussi parfaitement sous Mono.

Donc, dire que la finalité de .NET est d'exécuter le code sur un seul OS, c'est soit de la mauvaise foi, soit un manque de connaissance.

Oui, c'est un gros avantage de .Net: int, double, ... sont des classes et non pas des "types" comme en Java.

D'autant que je sache et après avoir étudié le CIL, ce n'est pas le cas. Int, double etc. ne sont pas des classes en .NET.
Cependant, il est vrai que le C# implémente de l'auto-boxing et peut faire croire que ce sont des objets. Mais c'est une spécificité de C# et non de .NET.

En java, le seul moyen de retourner une "nouvelle" valeur, c'est d'utiliser la variable de retour de la methode. Je trouve ca assez logique. Mais c'est vrai que c'est lourd quans tu veux retourner 2 "int". Soit tu retournes un tableau de int[], soit tu crées une nouvelle definition de classe/interface pour le retour

Je trouve ça passablement ridicule et risible. Comment un langage actuel peut avoir de si gros problèmes pour gérer un cas si basique ?
La solution du tableau est extrêmement peu sûre, et la définition d'une classe juste pour le retour est lourde et verbeuse.
La lourdeur de la seconde solution poussera un développeur un peu fainéant à utiliser la première technique. Et tu oses, après ça, parler de sécurité de Java ? Personnellement, si je veux renvoyer les valeurs x et y, je veux pouvoir écrire "x, y". Et rien de plus.

Enfin, ce qui m'attire avant tout vers .NET, c'est le choix du langage. Je trouve le langage très moche, peu pratique et extraordinairement verbeux (ce dernier point n'est une question de goût : de nombreux comparatifs existent). Je ne dis pas que C# est mieux (il me semble toutefois légèrement plus agréable à utiliser, mais je ne souhaite pas argumenter là-dessus), mais .NET offre le choix du langage. J'utilise quotidiennement F# (une variante d'OCaml pour .NET) et je suis assez impressionné de ce que l'on peut faire. Tous les comparatifs que j'ai vus s'accordent à dire que le code est minimum 2 fois plus court que son équivalent Java ; la lisibilité et la sûreté du code sont également très largement accrues.

Bref, à moins que la plateforme Java ne m'offre un langage fonctionnel de qualité, je ne l'utiliserai jamais.

[FremyCompany]

VB .Net aussi gère les nombres en tant qu'objet

Seul l'IL (et le COBOL .NET, dont on n'entend jamais parler tellement il est rare et couteux (pas gratuit)) ne le fait pas, à ma connaissance...

[yannart]

La finalité de .NET est d'être complètement portable. Ce n'est pas encore parfait, mais ça va dans ce sens.

Je ne suis pas d'accord, que je sache une chose c'est .NET développé par Microsoft et qui, au départ, n'a jamais eu l'intention de fonctionner en dehors de Windows. Et une chose c'est Mono qui à un certain retard sur la version originale et qui lui se veut portable effectivement.

[Médinoc]

Au sujet de ces histoires de "en tant qu'objet", je rappelle que .Net fait mieux que java la différence entre types valeur et types références, car même des types complexes peuvent être des types valeur. C'est la différence entre "ref class" et "value class" (C++/CLI) ou entre "class" et "struct" en C#.

Sachant que tout type valeur PEUT être boxé dans un objet, mais en C# on n'accède à une référence d'objet "boxé" que par une référence ce type Object. En C++/CLI, on peut directement utiliser un handle (pointeur managé) typé pour accéder aux objets boxés.


Donc, au niveau des types valeur ou référence, .Net donne une plus grande liberté et de meilleures performances en dispensant certains types complexes de l'allocation dynamique (notamment DateTime)...

[LLB]

VB .Net aussi gère les nombres en tant qu'objet
Seul l'IL (et le COBOL .NET, dont on n'entend jamais parler tellement il est rare et couteux (pas gratuit)) ne le fait pas, à ma connaissance...

Ainsi que F# (qui, lui, est gratuit et ses sources sont accessibles).

Je ne suis pas d'accord, que je sache une chose c'est .NET développé par Microsoft et qui, au départ, n'a jamais eu l'intention de fonctionner en dehors de Windows.

D'autant que je sache, si. Le système est prévu pour être indépendant de l'OS et les spécifications sont publiées. C'est donc bien pour permettre des implémentations sur d'autres OS. Effectivement, l'implémentation de Microsoft n'est pas portable, mais ce n'est pas gênant. Au final, on peut trouver une implémentation sur plusieurs OS, notamment grâce à Mono. Le CIL est donc portable.

[kisitomomotene]

Ainsi que F# (qui, lui, est gratuit et ses sources sont accessibles).

D'autant que je sache, si. Le système est prévu pour être indépendant de l'OS et les spécifications sont publiées. C'est donc bien pour permettre des implémentations sur d'autres OS. Effectivement, l'implémentation de Microsoft n'est pas portable, mais ce n'est pas gênant. Au final, on peut trouver une implémentation sur plusieurs OS, notamment grâce à Mono. Le CIL est donc portable.

Non je crois que le fait que le cil soit portable ou non est négligeable. D'après moi ce qui est le plus important dans la portabilité sont des librairies standard. Cela sert à quoi d'avoir un .Net portable s'il te faut reécrire 60% des bibliothéques utilisées pour passer de windows à Linux?. Sur ce point là la communauté Java concoit ses bibliothéques avec la portabilité en tête. Si MS ne reécrit ses biblithèques avec la portabilité en tête, chui désolé le niveau de portabilité de .Net sera insignifiant. D'ailleur Visual studio qui est le principal point fort de .Net devra aussi avoir une version Linux....Ce n'est pas pour demain ça.
Pour me resumer les solutions MS represente plus de 90% du succès de .Net (en fait je n'ai pas voulu dire 100%). Si MS ne rend pas portable ses solutions, il est illussoir de dire .Net est portable

[pseudocode]

Je m'auto-quote:

- Le finalité de .Net est utiliser N'IMPORTE QUEL langage pour implémenter une application qui s'executera sur UN OS (windows).

L'objectif de Microsoft est d'etre leader sur le marché des OS. Dans cet objectif, Ms développe continuellement une nouvelle version de son OS et force son adoption en arretant la vente des versions anterieurs. Ce n'est pas une critique ni un troll: c'est un fait et une politique somme toute assez logique (utilisé egalement par les firmes automobiles).

Le probleme pour Ms c'est a la fois de fournir des nouvelles versions d'OS mais également de conserver son "parc" de logiciels tiers (freeware, shareware, commerciaux) qui lui garantit son leadership.

Jusqu'a présent, Ms a garanti une compatibilité ascendante via des API "deprecated", des sous-systemes (wow 16bits) ou des patchs (Application Compatibility Database).

Mais comme rien n'est parfait, les editeurs tiers sont souvent obligés de ré-écrire leurs logiciels pour se plier aux nouveautés de l'OS. Cela freine l'adoption de l'OS par les utilisateurs: pas question de changer d'OS tant que l'application XXXX ne sera pas fonctionnelle !

Ce frein par les utilisateurs en entraine un autre, celui des editeurs qui doivent porter leur application sur le nouvel OS: a quoi bon porter notre application XXXX sur le nouvel OS si les utilisateurs sont toujours sous l'ancien OS ?

Ajoutez a cela la competition avec les solutions non-Ms (Linux, Php, Java, ...) et vous aurez un appercu de la problematique de Microsoft.

Je suppose donc que Ms a cherché un moyen de concilier ces problemes et a aboutit a la solution du "framework" de developpement et d'execution:

- Chers editeurs tiers, développez votre logiciel en .Net (dans votre langage habituel) et Microsoft vous garantit que ce logiciel fonctionnera sur XP, Vista, et les futurs OS.

- Chers utilisateurs, achetez le nouveau Windows sur lequel tous vos logiciels habituels sont pleinement fonctionnels.

- Chers décideurs informatiques, abandonnez Linux/Java et prennez Windows/.Net: une solution déja déployée sur 90% des PC (= part de marché de l'OS)

- Chers developpeurs de Redmond, inutile de garantir la compatibilité ascendante des API sur le prochain OS: contentez vous de fournir une version adaptée de la Virtual-Machine .Net

NB: Je ne pense pas que Ms a créé .Net dans l'espoir que le parc des logiciels Windows tourne sur Linux.

[FremyCompany]

D'autant que je sache, si. Le système est prévu pour être indépendant de l'OS et les spécifications sont publiées. C'est donc bien pour permettre des implémentations sur d'autres OS. Effectivement, l'implémentation de Microsoft n'est pas portable, mais ce n'est pas gênant. Au final, on peut trouver une implémentation sur plusieurs OS, notamment grâce à Mono. Le CIL est donc portable.

En effet, le CIL est tout à fait prévu pour être portable (une même application peut, si elle est concue pour (donc en évitant certaines spécicités des OS) fonctionner à la vois sous PocketPC et sous Windows... Le CIL, c'est comme Java, c'est prévu pour être portable, seulement, chez MS, on s'y connait pas assez en Linux pour faire le travail de portage

[gadj28]

Bonjour,

Je viens de lire les quelques 30 pages sur un sujet qui m'intéresse en ce moment, .NET/C# vs Java.

En fait, je me focalise sur un problème un peu plus précis, c'est-à-dire les communications sur le Web, d'une part directement via XML (en http), et d'autre part avec les Web Services.

J'ai travaillé pendant deux ans sur du J2EE, et maintenant depuis un an sur .NET. Mais je me demande si les deux plateformes fournissent les mêmes outils pour les WS, depuis combien de temps c'est disponible avec J2EE...

Bref, si quelqu'un a des infos là dessus, je suis preneur!

[osma_1978]

Salut à tous.

Un des points forts de Java vs .Net est le nombre de logiciels Opensources fiables disponibles. Là c'est un avantage considérable de Java. Avec .Net on est obligé en général de tout écrire à zéro et on perd en productivité ou bien d'acheter une solution propriètaire et on perd en souplesse(on n'est pas libre d'y faire ce que l'on veut), alors qu'avec Java et sa communauté open source, on peut gagner à la fois en souplesse et en productivité
Voilà.

Tu crois que les logiciels OpenSource développé en JAVA peuvent étre de meilleur qualité, et qu'on peux développé des applications à la base de ses logiciel sans aucun risque , je crois que tu va étre dépond 100% au éditeurs des ces logiciels et tu va payé ce que tu n'à pas payé.

[berceker united]

Tu crois que les logiciels OpenSource développé en JAVA peuvent étre de meilleur qualité, et qu'on peux développé des applications à la base de ses logiciel sans aucun risque , je crois que tu va étre dépond 100% au éditeurs des ces logiciels et tu va payé ce que tu n'à pas payé.

Désolé j'ai pas compris cette derniere phrase

[blbird]

C# n'est pas comparable à Java. C'est une daube incommensurable qui s'inspire à la fois de C, de C++, d'Ada et de Java dont c'est un mauvais clone.
Quand tu travailles en entreprises, le code unsafe on n'en veut pas donc c'est vraiment une fonctionnalité ridicule comme deux mots-clés pour déclarer une constante là où Java n'en prend qu'un seul et il y a plein d'autres exemples de ce style dans ce langage. Le problème est que C# a été contraint de récupérer des aspects de C++.NET et le résultat est plutôt médiocre. Les delegates en C# sont en fait de vulgaires pointeurs de fonctions, c'est du vent! Le seul aspect que j'ai trouvé pas mal bien que non portable c'est le chargement des DLL qui est très très facile dans ce langage.
Java est réduit au strict nécessaire dans sa syntaxe alors que C# est beaucoup moins concis. Désolé de rappeler également que C# est très loin d'être aussi portable que Java. Je ne connais aucun téléphone mobile compatible C# à part quelques PDA sous Windows Mobile.

Perso : 8 ans de Java, puis 2 ans de C# (certif MCP asp.net 2.0 récemment d'ailleurs)
Je ne dirais qu'une chose devant tant d'ineptie : je trouve amusant que, si C# était un langage aussi pourrit, que Java ait pompé autant d'éléments du C# il n'y a pas longtemps

[adiGuba]

Perso : 8 ans de Java, puis 2 ans de C# (certif MCP asp.net 2.0 récemment d'ailleurs)
Je ne dirais qu'une chose devant tant d'ineptie : je trouve amusant que, si C# était un langage aussi pourrit, que Java ait pompé autant d'éléments du C# il n'y a pas longtemps

Il est plus facile de créer un langage de toute part que d'en faire évoluer un autre, en particulier lorsqu'on souhaite conserver une certaine compatibilité...

La plupart des "nouveautés" de Java 5.0 (sortie fin 2004) peuvent sembler inspirer de C# (sortie en 2001 il me semble) mais le travail avait commencer bien avant :

• La JSR 14 concernant les Generics a été créé en 1999. De plus la solution adopté est assez loin de celle de C# qui se rapproche plus des Templates du C++.
• La JSR 201 regroupant la plupart des autres évolutions du langage date de fin 2002, mais certaines étaient déjà discuter bien avant ( comme les enums dont le premier info d'intégration remonte à début 2001 : http://bugs.sun.com/bugdatabase/view...bug_id=4093668 ).

Pour info les JSR correspondent aux processus d'intégrations de nouvelles fonctions/API dans la plateforme Java. Et lors de leurs créations elles subissent un vote de différents membres de la communauté Java... donc cela signifie que cela a déjà été pas mal discuté.


Par contre je reste persuadé que la sortie de C# a accélérer l'intégration de ces nouveautés...

Java a une approche plus "industrielle" où on évite de tout casser et de tout changer, ce qui fait qu'il a une évolution beaucoup plus lente... contrairement à C# qui a une évolution bien plus rapide.

Pour info la blogosphère Java parle énormément de nouvelles fonctionnalité à intégrer dans le langage, mais très peu sont se sont déjà concrétisé par une JSR...

a++

[FremyCompany]

Il est plus facile de créer un langage de toute part que d'en faire évoluer un autre, en particulier lorsqu'on souhaite conserver une certaine compatibilité...

Oui, c'est sûr. Mais reste néamoins, qu'au final, c'est le résultat qui compte.

Java a une approche plus "industrielle" où on évite de tout casser et de tout changer, ce qui fait qu'il a une évolution beaucoup plus lente... contrairement à C# qui a une évolution bien plus rapide.

L'argument ne me semble pas vraiment correct. C# et tous les languages de la plateforme DotNet apportent beacoup d'améliorations à chaque nouvelle version du framework (type génériques, LINQ, ...), alors même qu'un code écrit pour .NET 1.0 reste utilisable en .NET 3.5. Chaque fonctionnalité est ajoutée au framework, mais la base ancienne reste utilisable dans sa très grande majorité. La compatiblité transcendante est donc bien respectée, ce qui n'a pas empeché les langages d'évoluer...

[adiGuba]

Oui, c'est sûr. Mais reste néamoins, qu'au final, c'est le résultat qui compte.L'argument ne me semble pas vraiment correct.

C'est surtout une différence au niveau des processus d'évolution.

• .NET propose des évolutions rapides sous la surveillance de Microsoft seulement.
• Java propose des évolutions plus lente encadrées par divers acteurs du monde Java via les JSRs...

C# et tous les languages de la plateforme DotNet apportent beacoup d'améliorations à chaque nouvelle version du framework (type génériques, LINQ, ...), alors même qu'un code écrit pour .NET 1.0 reste utilisable en .NET 3.5. Chaque fonctionnalité est ajoutée au framework, mais la base ancienne reste utilisable dans sa très grande majorité. La compatiblité transcendante est donc bien respectée, ce qui n'a pas empeché les langages d'évoluer...

Il s'agit ici de la compatibilité binaire... mais il n'y a pas seulement cela lorsque je parlais de "tout casser" !

Un exemple :

• En introduisant les Generics (.NET 2.0 si je ne me trompe pas), il a été introduit une nouvelle API de Collections dans le namespaces "System.Collections.Generic", en plus de l'ancienne du namespaces "System.Collections". Bien sûr cela ne casse pas la compatibilité mais cela implique d'important changement dans le code existant (sauf erreur les deux API sont incompatibles).
  
  
• Les Generics de Java 5.0 ont été décriés car ils prennent une voie différente (ils ne sont pas typesafe à l'exécution mais à la compilation seulement), mais ils ont permis d'adapter l'API de collection existante afin qu'elle utilise les Generics tout en restant compatible avec les codes et librairies existantes qui utiliserait toujours l'ancienne API. On peut conserver le code existant sans modification et quand même utiliser les Generics...

L'industrie Java aurait mal accepté de devoir changer toutes les codes/librairies qui utilisaient l'ancienne API pour utiliser la nouvelle avec les Generics...

Pour .NET cela a été plus facile grâce justement à la jeunesse du langage (.NET avait environ 4 ans pour la sortie de .NET 2.0 - Java avait 9 ans lors de la sortie de Java 5.0).



Par contre je n'ai jamais dit qu'un des processus d'évolutions était meilleur que l'autre, chacun aillant ses avantages et ses défauts...

a++

[Médinoc]

Un exemple :

• En introduisant les Generics (.NET 2.0 si je ne me trompe pas), il a été introduit une nouvelle API de Collections dans le namespaces "System.Collections.Generic", en plus de l'ancienne du namespaces "System.Collections". Bien sûr cela ne casse pas la compatibilité mais cela implique d'important changement dans le code existant (sauf erreur les deux API sont incompatibles).
• Les Generics de Java 5.0 ont été décriés car ils prennent une voie différente (ils ne sont pas typesafe à l'exécution mais à la compilation seulement), mais ils ont permis d'adapter l'API de collection existante afin qu'elle utilise les Generics tout en restant compatible avec les codes et librairies existantes qui utiliserait toujours l'ancienne API. On peut conserver le code existant sans modification et quand même utiliser les Generics...

• Les generics .Net implémentent les interfaces non-génériques en plus des leurs.
• Les generics de java ne sont même pas pris en charge par le runtime (pas plus que les types valeurs non-primitifs comme DateTime, etc.)...

Pour moi, les seuls avantages techniques de Java sont sa portabilité actuelle et sa quantité de code existante (et encore, un wrapper COM peut faire bien des choses à ce sujet).

[Keihilin]

[LIST]
Pour moi, les seuls avantages techniques de Java sont sa portabilité actuelle et sa quantité de code existante (et encore, un wrapper COM peut faire bien des choses à ce sujet).

J'ajouterai que la quantité de code existante côté .Net est loin d'être négligeable et que bon nombre de framework et d'outils java ont été porté en .Net (avec parfois de franches améliorations).

La portabilité de .Net est encore à faire, mais elle est en bonne voie, c'est donc un argument en faveur de Java qui disparaîtra tôt ou tard.

Au passage, quand je lis des trucs comme

C# n'est pas comparable à Java. C'est une daube incommensurable qui s'inspire à la fois de C, de C++, d'Ada et de Java dont c'est un mauvais clone.
Quand tu travailles en entreprises, le code unsafe on n'en veut pas donc c'est vraiment une fonctionnalité ridicule comme deux mots-clés pour déclarer une constante là où Java n'en prend qu'un seul et il y a plein d'autres exemples de ce style dans ce langage. Le problème est que C# a été contraint de récupérer des aspects de C++.NET et le résultat est plutôt médiocre. Les delegates en C# sont en fait de vulgaires pointeurs de fonctions, c'est du vent! Le seul aspect que j'ai trouvé pas mal bien que non portable c'est le chargement des DLL qui est très très facile dans ce langage.
Java est réduit au strict nécessaire dans sa syntaxe alors que C# est beaucoup moins concis. Désolé de rappeler également que C# est très loin d'être aussi portable que Java. Je ne connais aucun téléphone mobile compatible C# à part quelques PDA sous Windows Mobile.

j'hésite entre le gros éclat de rire et la philosophie "il ne faut pas répondre aux imbéciles, ça les instruit"...