Eh bien... Java est en fait plus portable. Mono n'est pas implémenté partout et il est considérablement en retard par rapport à l'implémentation de Microsoft. Le SDK Java semble rester mieux synchronisé entre les plates-formes (et il fonctionne sur plus de plates-formes).
Je dirais également que Java a plus de disponibilité d'outils sur toutes ces plates-formes, bien qu'il existe de nombreux outils disponibles pour .NET sur les plates-formes Windows.
Mise à jour pour 2014
J'ai toujours cette opinion en 2014. Cependant, je nuancerai cela en disant que je commence tout juste à prêter attention à Mono après un long moment sans vraiment m'en soucier, donc il peut y avoir des améliorations dans le runtime Mono (ou écosystème ) dont je n'ai pas été informé. AFAIK, il n'y a toujours pas de support pour WPF, WCF, WF, de WIF. Mono peut fonctionner sur iOS, mais à ma connaissance, le runtime Java fonctionne toujours sur beaucoup plus de plates-formes que Mono. De plus, Mono commence à voir des outils bien améliorés (Xamarin), et Microsoft semble avoir une attitude beaucoup plus multiplateforme et une volonté de travailler avec des partenaires pour les rendre complémentaires plutôt que compétitifs (par exemple, Mono sera une partie assez importante du futur paysage OWIN/Helios ASP.NET). Je soupçonne que dans les années à venir, les différences de portabilité s'atténueront rapidement, en particulier après l'ouverture de .NET.
Mise à jour pour 2018
Mon point de vue à ce sujet commence à aller dans l'autre sens. Je pense que .NET, au sens large, en particulier avec .NET Core, a commencé à atteindre la "parité de portabilité" avec Java. Des efforts sont en cours pour intégrer WPF à .NET Core pour certaines plates-formes, et .NET Core lui-même s'exécute désormais sur un grand nombre de plates-formes. Mono (détenu par Xamarin, qui appartient maintenant à Microsoft) est un produit plus mature et raffiné que jamais, et l'écriture d'applications qui fonctionnent sur plusieurs plates-formes n'est plus le domaine de la gnose profonde du piratage .NET, mais est une entreprise relativement simple. . Il existe, bien sûr, des bibliothèques, des services et des applications qui sont uniquement Windows ou ne peuvent cibler que des plates-formes spécifiques - mais on peut en dire autant de Java (au sens large).
Si j'étais à la place de l'OP à ce stade, je ne vois aucune raison inhérente aux langages ou aux piles technologiques elles-mêmes qui m'empêcherait de choisir .NET pour toute application à partir de maintenant.
Mono réussit mieux à cibler les plates-formes que je souhaite prendre en charge. A part ça, tout est subjectif.
Je partage du code C# sur les plates-formes suivantes :- iOS (iPhone/iPad)- Android- Le Web (HTML5)- Mac (OS X)- Linux- Windows
Je pourrais le partager encore plus d'endroits :- Windows Phone 7- Wii- XBox- PS3- etc.
Le gros problème est iOS puisque MonoTouch fonctionne à merveille. Je ne connais aucun bon moyen de cibler iOS avec Java. Vous ne pouvez pas cibler Windows Phone 7 avec Java, donc je dirais que l'époque où Java était meilleur pour les mobiles est derrière nous.
Le facteur le plus important pour moi est la productivité personnelle (et le bonheur). C # en tant que langage a des années d'avance sur Java IMHO et le framework .NET est un plaisir à utiliser. La plupart de ce qui est ajouté dans Java 7 et Java 8 est en C# depuis des années. Les langages JVM comme Scala et Clojure (tous deux disponibles sur le CLR) sont plutôt sympas.
Je vois Mono comme une plate-forme à part entière (une excellente) et je considère .NET comme l'implémentation Microsoft de Mono sur Windows. Cela signifie que je développe et teste d'abord sur Mono. Cela fonctionne à merveille.
Si Java et .NET (disons Mono) étaient des projets Open Source sans aucun soutien d'entreprise, je choisirais Mono plutôt que Java à chaque fois. Je pense que c'est juste une meilleure plate-forme.
.NET/Mono et la JVM sont d'excellents choix, même si j'utiliserais personnellement un autre langage que Java sur la JVM.
Mon avis sur certains des autres commentaires :
Problème :performances.
**Réponse :la JVM et le CLR fonctionnent mieux que ne le disent leurs détracteurs. Je dirais que la JVM est plus performante. Mono est généralement plus lent que .NET (mais pas toujours).
Personnellement, je prendrais ASP.NET MVC sur J2EE n'importe quel jour à la fois en tant que développeur et utilisateur final. La prise en charge de Google Native Client est également très intéressante. De plus, je sais que les mauvaises performances de l'interface graphique pour les applications Java de bureau sont censées appartenir au passé, mais je continue à en trouver des lentes. Là encore, je pourrais dire la même chose pour WPF. GTK# est cependant très rapide, il n'y a donc aucune raison pour qu'il soit lent.
Problème :Java dispose d'un plus grand écosystème de bibliothèques disponibles.
Réponse :probablement vrai, mais ce n'est pas un problème dans la pratique.
Pratiquement toutes les bibliothèques Java (y compris le JDK) s'exécutent sur .NET/Mono grâce à IKVM.NET. Cette pièce de technologie est une véritable merveille. L'intégration est incroyable; vous pouvez utiliser une bibliothèque Java comme si elle était native. Cependant, je n'ai eu à utiliser que des bibliothèques Java dans une seule application .NET. L'écosystème .NET/Mono offre généralement plus que ce dont j'ai besoin.
Problème :Java offre une meilleure prise en charge des outils (plus larges)
Réponse :Pas sous Windows. Sinon je suis d'accord. MonoDevelop est sympa cependant.
Je veux remercier MonoDevelop ; c'est un bijou. MonoDevelop intègre la plupart des outils que je souhaite utiliser, notamment la complétion de code (intellisense), l'intégration Git/Subversion, la prise en charge des tests unitaires, l'intégration SQL, le débogage, la refactorisation facile et la navigation dans les assemblages avec décompilation à la volée. C'est formidable d'utiliser le même environnement pour tout, du Web côté serveur aux applications mobiles.
Problème :Compatibilité entre les plates-formes.
Réponse :Mono est une base de code unique sur toutes les plates-formes, y compris Windows.
Développez d'abord pour Mono et déployez sur .NET sous Windows si vous le souhaitez. Si vous comparez .NET de MS à Java, Java a l'avantage en termes de cohérence entre les plates-formes. Voir la réponse suivante...
Problème :Mono est en retard sur .NET.
Réponse :Non, ce n'est pas le cas. À mon humble avis, il s'agit d'une déclaration souvent formulée mais incorrecte.
La distribution Mono de Xamarin est livrée avec C#, VB.NET, F#, IronPython, IronRuby et je pense peut-être Boo prêt à l'emploi. Le compilateur Mono C# est complètement à jour avec MS. Le compilateur Mono VB.NET est en retard sur la version MS. Les autres compilateurs sont les mêmes sur les deux plateformes (tout comme les autres langages .NET comme Nemerle, Boo et Phalanger (PHP) ).
Mono est livré avec une grande partie du code écrit par Microsoft, notamment le Dynamic Language Runtime (DLR), le Managed Extensibility Framework (MEF), F # et ASP.NET MVC. Parce que Razor n'est pas Open Source, Mono est actuellement livré avec MVC2 mais MVC3 fonctionne très bien sur Mono.
La plate-forme principale Mono a suivi le rythme de .NET pendant de nombreuses années et la compatibilité est impressionnante. Vous pouvez utiliser le langage C# 4.0 complet et même certaines fonctionnalités C# 5.0 aujourd'hui. En fait, Mono mène souvent .NET à bien des égards.
Mono implémente des parties de la spécification CLR que même Microsoft ne prend pas en charge (comme les tableaux 64 bits). L'une des nouvelles technologies les plus excitantes du monde .NET est Rosylyn. Mono propose le compilateur C # en tant que service depuis de nombreuses années. Une partie de ce que propose Rosylyn est également disponible via NRefractory. Un exemple où Mono est encore en avance serait les instructions SIMD pour accélérer les performances de jeu.
Microsoft propose un certain nombre de produits en plus de .NET qui ne sont pas disponibles dans Mono, d'où l'idée fausse sur le retard Mono. Windows Presentation Foundation (WPF), Entity Framework (EF), WCF (Windows Communication Foundation) sont des exemples de produits qui ne fonctionnent pas ou sont mal supportés sur Mono. La solution évidente consiste à utiliser des alternatives multiplateformes comme GTK#, NHibernate et ServiceStack à la place.
Problème :Microsoft est diabolique.
Réponse :Vrai. Et alors.
De nombreuses personnes proposent les raisons suivantes pour éviter d'utiliser Mono :
1) Vous ne devez pas utiliser Mono car la technologie Microsoft doit être évitée
2) Mono craint car il ne vous permet pas d'utiliser toutes les technologies proposées par Microsoft
Pour moi, il est clair que ces déclarations sont incompatibles. Je rejette la première affirmation, mais je sauterai cet argument ici. La deuxième affirmation est vraie pour toutes les alternatives .NET.
La JVM est une excellente plate-forme et l'explosion des langages JVM est impressionnante. Utilisez ce qui vous rend heureux. Pour l'instant, c'est souvent .NET/Mono pour moi.