Combien de bibliothèques y a-t-il pour Mono par rapport à Java?

Je n'ai pas la vue d'ensemble sur les deux alternatives mais j'ai une grande liberté de choix pour mon prochain projet. Je recherche des faits techniques concrets dans les domaines de

• performances (par exemple, on me dit que Java est bon pour le threading, et j'entends que l'optimisation du code d'exécution est devenue très bonne récemment pour .NET)
• portabilité dans le monde réel (il est à la fois destiné à être portable, quel est Catch-22 pour chacun?)
• disponibilité des outils ( CI , automatisation de construction, débogage, IDE)

Je recherche surtout ce que vous avez réellement vécu dans votre propre travail plutôt que les choses que je pourrais google. Mon application serait un service back-end traitant de grandes quantités de données à partir de séries chronologiques.

Ma principale plate-forme cible serait Linux.

Edit: Pour formuler ma question de manière plus adéquate, je suis intéressé par l'ensemble du package (bibliothèques tierces, etc.), pas seulement par la langue. Pour les bibliothèques, cela revient probablement à la question "combien de bibliothèques y a-t-il moins pour Mono que pour Java"?

Pour votre information, j'ai depuis choisi Java pour ce projet, car il semblait juste plus porté au combat du côté de la portabilité et il existe également depuis un certain temps sur les systèmes plus anciens. Je suis un peu triste à ce sujet, car je suis très curieux à propos de C # et j'adorerais y faire un gros projet, mais peut-être la prochaine fois. Merci pour tous les conseils.

Eh bien ... Java est en fait plus portable. Mono n'est pas implémenté partout, et il est nettement en retard sur 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 une plus grande 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

Je suis toujours de cet avis en 2014. Cependant, je nuancerai cela en disant que je commence tout juste à prêter attention à Mono après un long moment sans vraiment me soucier, donc il peut y avoir des améliorations dans le runtime Mono (ou l'é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. En outre, Mono commence à voir des outils bien améliorés (Xamarin), et Microsoft semble avoir une attitude et une volonté beaucoup plus multiplateformes 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,

Mise à jour pour 2018

Mon point de vue à ce sujet commence à aller dans l'autre sens. Je pense que .NET, dans son ensemble, en particulier avec .NET Core, a commencé à atteindre la «parité de portabilité» avec Java. Des efforts sont en cours pour amener WPF vers .NET Core pour certaines plates-formes, et .NET Core lui-même fonctionne maintenant sur un grand nombre de plates-formes. Mono (propriété de 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 qui ne peuvent cibler que des plates-formes spécifiques - mais on peut en dire autant de Java (en gros).

Si j'étais à la place de l'OP à ce stade, je ne peux penser à 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 ce point.

Mono cible mieux 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 biggie est iOS depuis MonoTouch fonctionne à . 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 l'est en C # depuis des années. Les langages JVM comme Scala et Clojure (tous deux disponibles sur le CLR) sont cependant assez 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 support d'entreprise, je choisirais Mono plutôt que Java à chaque fois. Je pense que c'est simplement une meilleure plateforme.

.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 ce que disent leurs détracteurs. Je dirais que la JVM fonctionne mieux. Mono est généralement plus lent que .NET (mais pas toujours).

Personnellement, je prendrais ASP.NET MVC sur J2EE tous les jours 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 très rapide, donc il n'y a aucune raison pour laquelle ils doivent être lents.

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) ne fonctionnent que dandy sur .NET / Mono grâce à IKVM.NET . Cette pièce de technologie est une vraie merveille. L'intégration est incroyable; vous pouvez utiliser une bibliothèque Java comme elle était native. Cependant, je n'ai eu à utiliser que les 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 a une meilleure prise en charge des outils (plus larges)

Réponse: pas sous Windows. Sinon je suis d'accord. MonoDevelop est bien cependant.

Je tiens à remercier MonoDevelop ; c'est un bijou. MonoDevelop intègre la plupart des outils que je souhaite utiliser, y compris 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 d'assemblage avec décompilation à la volée. Il est merveilleux 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-le 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 à la traîne .NET.

Réponse: Non, ce n'est pas le cas. IMHO, c'est une déclaration souvent déclarée mais incorrecte.

La distribution Mono de Xamarin est fournie avec C #, VB.NET, F #, IronPython, IronRuby et je pense que Boo est peut-être prêt à l'emploi. Le compilateur Mono C # est complètement à jour avec MS. Le compilateur Mono VB.NET est en retard par rapport à la version MS. Les autres compilateurs sont les mêmes sur les deux plates-formes (comme le sont d'autres langages .NET comme Nemerle, Boo et Phalanger (PHP)).

Mono est livré avec une grande partie du code écrit de Microsoft, y compris le Dynamic Language Runtime (DLR), 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 ou 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 dirige souvent .NET de plusieurs manières.

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 intéressantes 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 . Les instructions SIMD pour accélérer les performances de jeu sont un exemple où Mono est toujours en avance.

Microsoft propose un certain nombre de produits en plus de .NET qui ne sont pas disponibles en Mono, d'où vient l'idée erronée du 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 pris en charge sur Mono. La solution évidente consiste à utiliser à la place des alternatives multiplateformes telles que GTK #, NHibernate et ServiceStack.

Problème: Microsoft est diabolique.

Réponse: vrai. Et alors.

De nombreuses personnes invoquent 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 est nul 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 déclaration, mais je vais sauter cet argument ici. La deuxième déclaration 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.

En fait, je développe en .NET, j'exécute tous mes tests d'abord sur Mono, puis sur Windows. De cette façon, je sais que mes applications sont multiplateformes. J'ai fait cela avec beaucoup de succès sur les applications ASP.NET et Winforms.

Je ne sais pas vraiment d'où certaines personnes ont l'impression que Mono est si horrible, mais il a certainement fait son travail dans mes cas et mes opinions.Il est vrai que vous aurez un peu de retard pour les dernières et les plus grandes inventions du .NET monde, mais jusqu'à présent, .NET 2.0 sur Windows et Linux est très solide pour moi.

Gardez à l'esprit qu'il y a évidemment de nombreuses bizarreries à cela, mais la plupart d'entre elles viennent de vous assurer que vous écrivez du code portable. Alors que les frameworks font un excellent travail d'abstraction du système d'exploitation sur lequel vous utilisez, de petites choses comme la sensibilité à la casse de Linux dans les chemins et les noms de fichiers demandent un peu de temps pour s'habituer, tout comme les autorisations.

.NET est définitivement très multiplateforme grâce à Mono basé sur mes expériences jusqu'à présent.

Java est en fait aussi multiplateforme que tout le monde le dit. Il existe une implémentation JVM pour à peu près tous les systèmes d'exploitation grand public (même Mac OS X, enfin), et ils fonctionnent tous très bien. Et il existe des tonnes d'outils open source qui sont tout aussi multiplateformes.

Le seul problème est qu'il existe certaines opérations natives que vous ne pouvez pas effectuer en Java sans écrire des DLL ou des SO. Il est très rare que cela se produise dans la pratique. Dans tous ces cas, cependant, j'ai pu le contourner en créant des processus natifs et en analysant les résultats.

Je pense que la question est mal formulée. C # vs Java est beaucoup moins intéressant en termes d'utilisation multiplateforme que (a) quelles plates-formes vous devez prendre en charge, et (b) compte tenu des bibliothèques de base et des bibliothèques tierces disponibles. La langue est presque la partie la moins importante du processus de prise de décision.

Java est un meilleur choix pour le développement multiplateforme.

• Performance. Java et .Net ont un niveau de performance similaire en raison de la machine virtuelle, mais JVM a normalement de meilleures performances en raison d'années et d'années d'optimisation.

• Bibliothèque. Bien que cela dépende de votre tâche, Java a beaucoup plus de bibliothèques open source ou tierces disponibles. Pour les applications serveur, J2EE, Spring, Struts, etc. Pour l'interface graphique, bien que .Net fournisse une API de couche Win32, mais cela pose des problèmes de compatibilité. Java a Swing, SWT, AWT, etc. Cela fonctionne dans la plupart des cas.

• Compatibilité. Ce sont les questions clés qui doivent être prises en compte lors du développement du programme multiplateforme. Deux problèmes: premièrement, la compatibilité des plates-formes. Java gagne toujours puisque JDK est bien entretenu par la société unique et originale Sun. Mono n'est pas maintenu par MS, vous n'avez donc pas encore de garantie pour la compatibilité des mises à jour. 2. Rétrocompatibilité. Sun maintient une bonne réputation sur leur compatibilité descendante, même si cela semble parfois trop rigide et ralentit le rythme.

• Outils. Java a de bons IDE multiplateformes. Netbeans, Eclipse, etc. La plupart d'entre eux sont gratuits. VS Studio est bon mais uniquement sur Windows et ne coûte pas un peu. Les deux fournissent de bons tests unitaires, des débogages, des profils, etc.

Par conséquent, je suggère que Java est un meilleur choix. À titre de démonstration, il existe des applications de bureau multiplateformes célèbres développées par Java: Vuze, Limewire, BlogBridge, CrossFTP, sans oublier ces IDE. En ce qui concerne .Net, j'ai des connaissances limitées sur ces applications à succès.

J'ai posé la même question tardivement et à mon humble avis, .NET / Mono semble être une meilleure option simplement parce que Mono a un excellent bilan pour les applications de bureau multiplateformes (par opposition à Java) et bien sûr, Mono est amélioration à pas de géant ces jours-ci.

Je vais également dire Java. Si vous considérez cela en termes de maturité, Sun (et d'autres) ont consacré beaucoup plus de temps et d'efforts pour faire fonctionner la JVM sur des plates-formes non Windows.

En revanche, Mono est définitivement un citoyen de deuxième classe dans l'écosystème .NET.

En fonction de vos clients cibles, vous constaterez peut-être également qu'il existe une réelle opposition à l'utilisation de Mono - Novell offre-t-il le même type de support de fournisseur pour Mono que vous obtiendriez pour Java ou .NET sur Windows?

Si vous visiez principalement l'hébergement de votre service sur Windows, il serait logique d'envisager ce choix, mais comme vous ciblez principalement Linux, cela me semble une évidence.

Java a été conçu pour être multiplateforme; C # /. Net ne l'était pas. En cas de doute, utilisez l'outil qui a été conçu pour vous.

EDIT: en toute honnêteté, .NET a été conçu pour fonctionner sur des environnements embarqués / PC / Serveur, c'est donc TRIER de multi-plateforme. Mais il n'a pas été conçu pour Linux.

Je pense que la réponse est «cela dépend». Java fonctionne sur à peu près tout, mais .NET / Mono est (à mon humble avis) un meilleur cadre pour le bureau. Je suppose donc que la réponse dépend vraiment des plates-formes que vous prévoyez de cibler.

Pour ajouter un peu plus à la conversation, Java est plus portable si vous restez environ une version derrière - Java 5 a encore de nombreuses fonctionnalités excellentes, vous pouvez donc attendre Java 6 et avoir encore beaucoup de gamme en termes de langage et de bibliothèques à développer avec. Le Mac est la principale plate-forme qui peut prendre un certain temps pour rattraper la dernière version de Java.

Java dispose également d'un excellent organisme de normalisation qui développe intelligemment la plate-forme en fonction des contributions de nombreuses entreprises différentes. C'est une fonctionnalité souvent négligée, mais elle permet même aux nouvelles fonctionnalités de bien fonctionner sur plusieurs plates-formes et offre une large gamme de support de bibliothèque pour certaines choses ésotériques (en tant qu'extensions facultatives).

Je voterais pour que Java soit plus portable que C #. Java possède également un ensemble très riche de bibliothèques standard. Il existe également un large éventail de bibliothèques tierces open source telles que celles fournies par le projet Jakarta ( http://jakarta.apache.org/ ).

Tous les suspects habituels existent également pour les CI, les tests unitaires, etc. Le support IDE multiplateforme est également très bon avec Eclipse, Netbeans, IntelliJ IDEA, etc.

Il existe également d'autres choix linguistiques. Je suis devenu assez friand de Python, qui fonctionne bien sur Windows, Linux et Mac, et possède un riche ensemble de bibliothèques.

Alors que Mono a son lot de problèmes je pense qu'il a une meilleure histoire de compatibilité multiplateforme, en particulier SI vous comptez sur l'invocation de la plate-forme native.

Il n'y a pas assez de mots sur Stack Overflow pour souligner à quel point il est plus facile d'obtenir quelque chose de natif appelé et exécuté en .NET / Mono sur (au moins dans mon expérience 3 ...) plusieurs plates-formes par rapport à l'effort Java équivalent.

Gatorhall , avez-vous des données pour étayer cela?

Performance. Java et .Net ont un niveau de performance similaire en raison de la machine virtuelle, mais JVM a normalement de meilleures performances en raison d'années et d'années d'optimisation.

Contexte: Je suis un gars de Windows depuis Windows 3.1 et actuellement un utilisateur de Linux (toujours sous Windows 7, excellent système d'exploitation, sur une machine virtuelle pour Visual Studio 2010 et d'autres outils).

Le point: moi et beaucoup d'utilisateurs (Windows, Linux, etc.) je sais, peut-être en désaccord avec vous. Java a tendance à fonctionner plus lentement, même sur une application de bureau Linux, ASP.NET est souvent plus rapide que les pages du serveur Java. Certains peuvent convenir que même PHP non compilé fonctionne mieux dans plusieurs scénarios.

Java est plus multiplateforme? Je n'ai aucun doute à ce sujet (l'historique sur ce point), mais plus rapide (sans dire que .NET est) pas si sûr et j'aimerais voir de vrais repères.