Est-ce que .NET / Mono ou Java est le meilleur choix pour le développement multiplateforme? [fermé]


108

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.


3
Excellente question. Nous envisageons également une évaluation pour le développement multiplateforme.
Mat Nadrofsky

J'ajouterais la balise "which-language" mais il y en a déjà 5, donc pas de chance.
Daniel Daranas le

Cela dépend fortement des plates-formes que vous ciblez ...
Thorbjørn Ravn Andersen

1
C'est peut-être le bon moment pour vous de regarder golang ...
StartupGuy

Xojo pourrait également valoir la peine d'être envisagé. Il compile des applications natives en utilisant LLVM pour Windows, Mac Linux. Il a une automatisation de construction IDE, un débogage, etc. La bibliothèque a beaucoup de fonctionnalités et peut être étendue si nécessaire. www / xojo.com
Paul Lefebvre

Réponses:


96

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.


2
Je suis vraiment content de lire ceci et joyeux au sujet des votes dans un monde Microsoft. .NET est vraiment bon mais Java a une légitimité comme j'ai toujours essayé de l'expliquer en tant que développeur .NET et ancien Java;)
JoeBilly

+1 pour cela. J'ai trouvé que la portabilité Java (pour les applications non triviales, c'est-à-dire les serveurs Web, les interfaces graphiques complexes, les moteurs d'analyse) était meilleure que toute autre alternative. Ce n'est pas tout à fait parfait, mais c'est le meilleur que vous puissiez obtenir en ce moment.
mikera

1
@Ben, avez-vous toujours cette opinion en 2013? Si vous le faites, pourriez-vous le mentionner et si vous ne mettez pas à jour cette réponse? Souvent, en lisant les réponses des enfants de 4 ans, c'est difficile à dire.
Benjamin Gruenbaum

1
@BenjaminGruenbaum oui, même si je nuancerais mon opinion à ce stade en disant que je n'ai pas accordé beaucoup d'attention à Mono depuis longtemps, donc il peut y avoir des améliorations dans le runtime Mono (ou l'écosystème) que je n'ai pas été mis au courant. AFAIK, il n'y a toujours pas de support pour WPF, WCF ou WF. Mono peut fonctionner sur iOS, mais à ma connaissance, le runtime Java fonctionne toujours sur beaucoup plus de plates-formes que Mono. Donc oui. Qualifié, mais oui.
Ben Collins

@HighCore l'argument n'est pas contre Mono, en soi. C'est juste une déclaration de fait: si vous écrivez du code dépendant de WPF, vous ne pouvez pas utiliser Mono; ergo, il n'est pas portable de cette façon. Les frameworks d'interface utilisateur de Java peuvent être nuls, mais pour autant que je sache, ils fonctionneront partout où Java fonctionne (et le matériel prend en charge ce type d'interface utilisateur). Cela ne rend pas Java meilleur , cela le rend plus portable de cette manière spécifique.
Ben Collins

112

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.


3
Merci pour une réponse aussi complète que tard dans le match. Je n'ai jamais utilisé Mono / .Net / C #, mais votre message semble refléter certains des développements les plus récents dans cet univers. Par exemple, je ne me souviens pas que MonoTouch était si important il y a 3,5 ans.
Hanno Fietz

3
Je suis confus par votre réponse "Mono ne traîne pas. NET". Vous prétendez cela, puis indiquez une demi-douzaine de façons dont il retarde en fait .NET (Entity Framework, etc.). Il est prudent de dire qu'il n'est pas à la traîne du compilateur C # de Microsoft, mais l'écosystème .NET est au mieux fragmentaire sur Mono. Cela semble convenir à vos besoins, mais pas à tout le monde, et il y a là une préoccupation légitime.
samkass

1
@samkass: Je pense que le point ici est la différence entre «retards» et «n'implémente pas cette bibliothèque». Dans le monde Java, vous pouvez trouver cela analogue à Android n'implémentant pas la bibliothèque Swing. Veuillez également noter que les équivalents multiplateformes (et open source, btw) ont été donnés. J'utilise Mono tous les jours et «fragmentaire au mieux» n'était certainement pas mon expérience.
konrad.kruczynski

9
Le manque de support WCF et EF complet et robuste, et l'absence de WPF est un tueur pour Mono pour à peu près tout ce sur quoi j'ai travaillé depuis .NET 3.0. Oui, il existe des alternatives, mais une grande partie de la puissance de .NET réside dans ces frameworks supplémentaires. Sans cela, je ne pense pas que vous puissiez appeler Mono compatible avec .NET du tout. C'est au mieux une implémentation partielle. J'ai également utilisé NHibernate et franchement EF est une technologie bien meilleure. Jamais utilisé ServiceStack. IMO Mono est très risqué.
MrLane

1
tous ceux qui manquent WCF devraient jeter un oeil à servicestack. sérieusement, ne pas implémenter WCF était une bonne chose!
irréel

54

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.


Appelez-moi ignorant, mais avez-vous même besoin de tester ASP.NET avec mono? Tout ce qui serait .NET est côté serveur, peu importe le système d'exploitation sur lequel il est affiché, n'est-ce pas?
Ethan Gunderson le

9
Ethan, en utilisant Mono, vous pouvez héberger des applications ASP.net sur Linux.
Eric Haskins le

2
Tout le monde ne souhaite pas exécuter son application sous Windows, quelle qu'en soit la raison.
Bernard

2
@ Rich B: si un client ne veut pas de produits MS, .NET est clairement le mauvais choix.
Kjetil Ødegaard

21
@Kjetil: Mono n'est pas un produit MS.
GEOCHET

26

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.


1
De plus, dans presque tous les cas où Java ne peut pas effectuer d'opération native de manière multiplateforme, il en sera de même pour .NET
Eli Courtwright

Finalement? Mac OS X a une implémentation JVM depuis la version 10.0. :)
mipadi

3
@Eli - Probablement vrai. Il est certainement beaucoup, beaucoup plus facile à intégrer avec les fonctionnalités natives de .NET / Mono que dans Java. Donc, si vous essayez simplement de bien vous intégrer à la plateforme native, .NET / Mono offre un réel avantage.
Justin

"engendrer des processus natifs et filtrer les résultats" frissonner
base

Je chipoterais avec `` à peu près n'importe quel système d'exploitation grand public '', car il n'y a pas de JVM prête à l'emploi pour Android ou iOS. Avec les nouvelles bibliothèques de classes portables de .NET, vous pouvez en fait partager du code compilé (mais pas pratiquement du code d'interface utilisateur) entre les plates-formes, y compris les mobiles.
Mathieson

18

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.


D'accord. Il s'agit de savoir dans quelle mesure les machines virtuelles sont bien prises en charge sur diverses architectures.
Allain Lalonde le

D'accord. Pas de plaisir à faire un développement complet si le client ne peut pas l'exécuter.
Thorbjørn Ravn Andersen

15

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.


Travailler avec mono sur «d'autres» Linux est devenu délicat. Cela reflète le problème majeur du mono: l'avenir du mono est trop dépendant de la dictature de Miguel de Icaza. Exemple concret: la diminution du support pour «autre ... (non pris en charge)» [ mono-project.com/Other_Downloads] Linux semble être en corrélation ( IMHO ) avec la désillusion de Miguel de Icaza avec Linux ( tirania.org/blog/archive/ 2013 / mars-05.html ). Java ne souffre pas de ce problème de dictature. C # peut fonctionner sur plus de plates-formes, mais cela entraîne plus de coûts, de risques, de compromis et de dépendance à l'égard de M. de Icaza. Non merci.
StartupGuy

@ Michael.M alors vous préférez être à la merci d'Oracle?
Thorbjørn Ravn Andersen

@ ThorbjørnRavnAndersen: Faux. Permettez-moi de le décomposer aussi simplement que possible: .Net -> plate-forme MSFT (entreprise stable à succès; éco-système limité mais soigné); Mono -> Framework De Icaza (el dictador; pas chaud pour Linux et cela montre: [ cultofmac.com/218632/… - essayez d'installer mono sur Centos 6.4, c'est un cauchemar "non supporté"); Java est une spécification qui appartient à la communauté et a de nombreuses implémentations de fournisseurs différentes (Oracle en est une) [ coderanch.com/t/327542/java/java/…
StartupGuy

@ ThorbjørnRavnAndersen: .. de plus, un sponsor majeur de la communauté Java peut même exclure Oracle tout en réussissant et extrêmement bien pris en charge - Java n'est en aucun cas à la merci d'Oracle --- veuillez consulter: news.techworld.com/applications/3252787/ … Oracle pourrait vider toute leur implication Java et continuerait à vivre. Quels autres fournisseurs ont une plate-forme .Net? Qui d'autre fournit un runtime mono autre que Xamarin? Java est le seul de ceux-ci à ne pas être soumis à la dictature et a un véritable contrôle communautaire, un soutien communautaire et une gestion communautaire.
StartupGuy

1
@ Spécifications Michael.M? Appartenant à la communauté? Je pense que vous vous trompez - je pense également que la seule raison pour laquelle le projet OpenJDK n’a pas été arrêté après l’acquisition de Sun était la GPL. Java est dans la main de fer d'Oracle, simplement parce que le TCK n'est pas disponible gratuitement et c'est ce qu'il faut pour faire une JVM qui se comporte comme la JVM Oracle. Je n'ai pas de problème avec Mono ou De Icaza, mais je ne pense pas que la situation de Java soit bien meilleure. Le seul projet JVM alternatif avec un élan est mort quand IBM a cessé de le soutenir.
Thorbjørn Ravn Andersen


8

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.


J'ai tendance à être d'accord avec Mono en tant que citoyen de 2e classe, mais pas avec la conclusion. Java existe depuis longtemps et est criblé de bizarreries héritées et de problèmes de gestion de la mémoire, pour ne pas dire qu'il choisit presque toujours la manière la plus verbeuse de faire quelque chose. Il a également été assez stagnant (le langage) pendant des années et n'a commencé que récemment à intégrer des fonctionnalités qui sont dans .Net depuis des années. À mon humble avis, c'est un choix entre deux maux ... Support de plate-forme Flakey avec .Net ou un monstre lourd qui est très lent à évoluer et une corvée à coder.
base

7

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.


3
eh bien, le C # est normalisé ISO, donc l'idée était d'avoir quelque chose de multiplateforme. Microsoft ne voulait pas développer d'implémentations pour d'autres plates-formes, mais cela est laissé à d'autres parties car le langage est un standard. le framework .Net est cependant une histoire plus compliquée.
zappan le

Mono est une bonne implémentation cependant et DotGNU (pour Mac aussi)
Andrei Rînea

1
zappan: point valide sur C # (ne savait pas), mais .NET est terriblement énorme. Certes, je n'ai aucune expérience personnelle ici.
AlexeyMK

@zappan - d'un point de vue pratique, il n'est pas pertinent que C # soit standardisé (ou que Mono fasse un assez bon clone de C #). La portabilité de la plate-forme concerne l'ensemble de la plate-forme (y compris les bibliothèques et l'écosystème d'outils), pas seulement le langage lui-même. En ce sens, .Net n'est certainement pas entièrement multiplateforme.
mikera

7

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.


Desktop n'est pas synonyme de Windows même s'il possède la plus grande partie de l'espace de bureau.
ZOXIS

6

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


OS X 10.6 a maintenant complètement rattrapé la sortie de Sun Java 6.
Thorbjørn Ravn Andersen

5

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.


4

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.


Ouais, j'adore Python et il a Django que j'aime pour les applications Web, mais il y avait certaines choses qui le rendaient inacceptable, le plus important étant le GIL dans l'implémentation C standard de l'interpréteur. J'ai un certain nombre d'opérations qui bénéficient grandement du calcul parallèle sur des machines multicœurs et je devrais générer des processus pour le faire en cPython.
Hanno Fietz

3

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.


Je suis d'accord, appeler du code spécifique à la plate-forme à partir de .NET / Mono est super facile tant qu'il peut être appelé à partir de C. Avec CXXI ​​(prononcé sexy), il devient aussi facile d'appeler du code C ++. tirania.org/blog/archive/2011/Dec-19.html
Justin

2

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.


Il y a une autre question qui peut aider et bien sûr il y a la fusillade linguistique . La JVM est peut-être plus fortement optimisée mais elle est proche (en particulier sous Windows). Les benchmarks pour ASP.NET vs J2EE ou JSP sont encore plus suspects mais je n'ai aucun mal à croire qu'ASP.NET est beaucoup plus rapide même si les temps d'exécution sont liés.
Justin
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.