Nun .... Java ist eigentlich portabler. Mono ist nicht überall implementiert und hinkt der Microsoft-Implementierung erheblich hinterher. Das Java SDK scheint plattformübergreifend besser synchron zu bleiben (und es funktioniert auf mehr Plattformen).
Ich würde auch sagen, dass für Java auf all diesen Plattformen mehr Tools verfügbar sind, obwohl es viele Tools für .NET auf Windows-Plattformen gibt.
Aktualisierung für 2014
Ich bin noch 2014 dieser Meinung. Ich schränke dies jedoch ein, indem ich sage, dass ich gerade jetzt beginne, Mono etwas Aufmerksamkeit zu schenken, nachdem ich mich lange Zeit nicht wirklich darum gekümmert habe, sodass es möglicherweise Verbesserungen in der Mono-Laufzeit (oder im Ökosystem) gibt ), auf die ich nicht aufmerksam gemacht wurde. AFAIK, es gibt immer noch keine Unterstützung für WPF, WCF, WF oder WIF. Mono kann auf iOS laufen, aber meines Wissens läuft die Java-Laufzeitumgebung immer noch auf weit mehr Plattformen als Mono. Außerdem beginnt Mono, einige stark verbesserte Tools (Xamarin) zu sehen, und Microsoft scheint eine viel plattformübergreifendere Haltung und Bereitschaft zu haben, mit Partnern zusammenzuarbeiten, um sie komplementär zu machen, anstatt wettbewerbsfähig zu sein (z. B. wird Mono sein ein ziemlich wichtiger Teil der kommenden OWIN/Helios ASP.NET-Landschaft). Ich vermute, dass sich die Unterschiede in der Portabilität in den kommenden Jahren schnell verringern werden, insbesondere nachdem .NET Open Source wurde.
Aktualisierung für 2018
Meine Ansicht dazu beginnt in die andere Richtung zu gehen. Ich denke, dass .NET im Allgemeinen, insbesondere mit .NET Core, damit begonnen hat, „Portabilitätsparität“ mit Java zu erreichen. Es gibt Bemühungen, WPF für einige Plattformen auf .NET Core zu bringen, und .NET Core selbst läuft jetzt auf sehr vielen Plattformen. Mono (im Besitz von Xamarin, das jetzt im Besitz von Microsoft ist) ist ein ausgereifteres und ausgefeilteres Produkt als je zuvor, und das Schreiben von Anwendungen, die auf mehreren Plattformen funktionieren, ist nicht länger die Domäne der tiefen Gnosis von .NET-Hackern, sondern ein relativ unkompliziertes Unterfangen . Es gibt natürlich Bibliotheken und Dienste und Anwendungen, die nur Windows sind oder nur auf bestimmte Plattformen abzielen können - aber das Gleiche gilt für Java (im Großen und Ganzen).
Wenn ich zu diesem Zeitpunkt in den Schuhen des OP stecken würde, kann ich mir keinen Grund vorstellen, der in den Sprachen oder Tech-Stacks selbst liegt, der mich davon abhalten würde, .NET für eine Anwendung von diesem Punkt an zu wählen.
Mono kann besser auf die Plattformen abzielen, die ich unterstützen möchte. Ansonsten ist alles subjektiv.
Ich teile C#-Code auf den folgenden Plattformen:– iOS (iPhone/iPad) – Android – Das Web (HTML5) – Mac (OS X) – Linux – Windows
Ich könnte es an noch mehr Stellen teilen:- Windows Phone 7- Wii- XBox- PS3- etc.
Das große Problem ist iOS, da MonoTouch fantastisch funktioniert. Ich kenne keine gute Möglichkeit, iOS mit Java anzusprechen. Sie können Windows Phone 7 nicht mit Java ansprechen, also würde ich sagen, dass die Zeiten, in denen Java besser für Mobilgeräte war, hinter uns liegen.
Der größte Faktor für mich ist jedoch die persönliche Produktivität (und das Glück). C# als Sprache ist meiner Meinung nach Java um Jahre voraus, und das .NET-Framework macht Spaß. Das meiste, was in Java 7 und Java 8 hinzugefügt wird, befindet sich seit Jahren in C#. JVM-Sprachen wie Scala und Clojure (beide in der CLR verfügbar) sind jedoch ziemlich nett.
Ich sehe Mono als eigenständige Plattform (eine großartige) und betrachte .NET als die Microsoft-Implementierung von Mono unter Windows. Das bedeutet, dass ich zuerst auf Mono entwickle und teste. Das funktioniert wunderbar.
Wenn sowohl Java als auch .NET (sagen wir mal Mono) Open-Source-Projekte ohne Firmenunterstützung wären, würde ich jedes Mal Mono statt Java wählen. Ich glaube, es ist einfach eine bessere Plattform.
Sowohl .NET/Mono als auch die JVM sind eine großartige Wahl, obwohl ich persönlich eine andere Sprache als Java auf der JVM verwenden würde.
Meine Meinung zu einigen anderen Kommentaren:
Problem:Leistung.
**Antwort:Sowohl die JVM als auch die CLR sind besser als Kritiker behaupten. Ich würde sagen, dass die JVM besser abschneidet. Mono ist im Allgemeinen langsamer als .NET (wenn auch nicht immer).
Ich persönlich würde sowohl als Entwickler als auch als Endbenutzer jeden Tag ASP.NET MVC über J2EE nehmen. Die Unterstützung für Google Native Client ist auch ziemlich cool. Ich weiß auch, dass schlechte GUI-Leistung für Desktop-Java-Apps der Vergangenheit angehören soll, aber ich finde immer wieder langsame. Andererseits könnte ich dasselbe für WPF sagen. GTK# ist jedoch ziemlich schnell, also gibt es keinen Grund, dass sie langsam sein müssen.
Problem:Java verfügt über ein größeres Ökosystem an verfügbaren Bibliotheken.
Antwort:Wahrscheinlich wahr, aber in der Praxis kein Thema.
Praktisch jede Java-Bibliothek (einschließlich des JDK) läuft dank IKVM.NET problemlos auf .NET/Mono. Dieses Stück Technik ist ein wahres Wunder. Die Integration ist erstaunlich; Sie können eine Java-Bibliothek genauso verwenden, als wäre sie nativ. Ich musste Java-Bibliotheken jedoch nur in einer .NET-App verwenden. Das .NET/Mono-Ökosystem bietet im Allgemeinen mehr als ich brauche.
Problem:Java unterstützt bessere (breitere) Tools
Antwort:Nicht unter Windows. Ansonsten stimme ich zu. MonoDevelop ist aber nett.
Ich möchte MonoDevelop loben; es ist ein Juwel. MonoDevelop integriert die meisten Tools, die ich verwenden möchte, einschließlich Codevervollständigung (Intellisense), Git/Subversion-Integration, Unterstützung für Komponententests, SQL-Integration, Debugging, einfaches Refactoring und Assembly-Browsing mit spontaner Dekompilierung. Es ist wunderbar, dieselbe Umgebung für alles zu verwenden, vom serverseitigen Web bis hin zu mobilen Apps.
Problem:Plattformübergreifende Kompatibilität.
Antwort:Mono ist eine einzige Codebasis für alle Plattformen, einschließlich Windows.
Entwickeln Sie zuerst für Mono und stellen Sie es auf .NET unter Windows bereit, wenn Sie möchten. Wenn Sie jedoch .NET von MS mit Java vergleichen, hat Java die Nase vorn, was die Konsistenz über Plattformen hinweg angeht. Siehe nächste Antwort...
Problem:Mono verzögert .NET.
Antwort:Nein, tut es nicht. IMHO, das ist eine oft geäußerte, aber falsche Aussage.
Die Mono-Distribution von Xamarin wird mit C#, VB.NET, F#, IronPython, IronRuby und ich denke, vielleicht ist Boo sofort einsatzbereit. Der Mono C#-Compiler ist komplett auf dem neuesten Stand von MS. Der Mono VB.NET-Compiler hinkt der MS-Version hinterher. Die anderen Compiler sind auf beiden Plattformen gleich (ebenso wie andere .NET-Sprachen wie Nemerle, Boo und Phalanger (PHP)).
Mono wird mit einem Großteil des von Microsoft geschriebenen Codes ausgeliefert, einschließlich Dynamic Language Runtime (DLR), Managed Extensibility Framework (MEF), F# und ASP.NET MVC. Da Razor nicht Open Source ist, wird Mono derzeit mit MVC2 ausgeliefert, aber MVC3 funktioniert problemlos mit Mono.
Die zentrale Mono-Plattform hat über viele Jahre mit .NET Schritt gehalten und die Kompatibilität ist beeindruckend. Sie können heute die vollständige C# 4.0-Sprache und sogar einige C# 5.0-Features verwenden. Tatsächlich ist Mono in vielerlei Hinsicht oft führend gegenüber .NET.
Mono implementiert Teile der CLR-Spezifikation, die selbst Microsoft nicht unterstützt (wie 64-Bit-Arrays). Eine der aufregendsten neuen Technologien in der .NET-Welt ist Rosylyn. Mono bietet den C#-Compiler seit vielen Jahren als Service an. Einiges von dem, was Rosylyn anbietet, ist auch über NRefractory verfügbar. Ein Beispiel dafür, wo Mono immer noch vorne liegt, wären die SIMD-Anweisungen zur Beschleunigung der Spieleleistung.
Microsoft bietet eine Reihe von Produkten zusätzlich zu .NET an, die nicht in Mono verfügbar sind, weshalb das Missverständnis über die Mono-Verzögerung herrührt. Windows Presentation Foundation (WPF), Entity Framework (EF), WCF (Windows Communication Foundation) sind Beispiele für Produkte, die auf Mono nicht funktionieren oder schlecht unterstützt werden. Die offensichtliche Lösung besteht darin, stattdessen plattformübergreifende Alternativen wie GTK#, NHibernate und ServiceStack zu verwenden.
Problem:Microsoft ist böse.
Antwort:Richtig. Na und.
Viele Leute nennen die folgenden Gründe, Mono zu vermeiden:
1) Sie sollten Mono nicht verwenden, da Microsoft-Technologie vermieden werden sollte
2) Mono ist scheiße, weil Sie nicht jede Technologie nutzen können, die Microsoft anbietet
Mir ist klar, dass diese Aussagen unvereinbar sind. Ich lehne die erste Aussage ab, überspringe dieses Argument hier aber. Die zweite Aussage gilt für alle .NET-Alternativen.
Die JVM ist eine großartige Plattform und die Explosion der JVM-Sprachen ist großartig. Nutze, was dich glücklich macht. Im Moment ist das für mich oft .NET/Mono.