Que choisiriez-vous pour votre projet entre .NET et Java à ce stade? [fermé]


13

Vous venez de commencer un nouveau projet et vous avez le choix entre ces deux technologies, Java et .NET. Le projet sur lequel vous travaillez n'implique pas de fonctionnalités qui faciliteraient le choix entre les deux technologies (par exemple, .NET a ce dont j'ai besoin et Java non) et les deux devraient fonctionner très bien pour vous (même si vous besoin d'un bien sûr). Prendre en compte:

  • Performance
  • Outils disponibles (même des outils tiers)
  • Compatibilité multiplateforme
  • Bibliothèques (en particulier les bibliothèques tierces)
  • Coût (Oracle semble essayer de monétiser Java)
  • Processus de développement (le plus simple / le plus rapide)

Gardez également à l'esprit que Linux n'est pas votre plate-forme principale, mais vous souhaitez également porter votre projet sur Linux / MacOs. Vous devez certainement garder à l'esprit les problèmes qui ont tourné autour d'Oracle et de la communauté Java ainsi que les limites de Mono et Java. Il serait très apprécié que les personnes ayant une expérience des deux puissent donner un aperçu et leur propre opinion subjective sur lesquelles elles choisiraient et pourquoi.

java  .net  mono 

Il n'y a pas suffisamment d'informations sur les exigences pour répondre efficacement à cette question.
red-dirt

3
Le mono est une douleur (par exemple, une perte de temps). Même un concepteur WinForm basique n'est pas là.
Job

@Job en fait, MonoDevelop a un concepteur graphique pour GTK #, car WinForms n'est pas encore open source.
Mahmoud Hossam

Oui, mais comment fonctionne Mono avec les bibliothèques tierces? Travaillent-ils "juste"? Et (peut-être plus important encore), les fournisseurs fournissent-ils une assistance si vous les utilisez avec Mono?
TMN

Réponses:


26

La décision la plus importante (modifier: technique) est la suivante:

  • Vous engagez-vous à ce stade à 100% à utiliser Windows comme future plate-forme de déploiement?

Si non, alors vous devriez opter pour Java.


La conclusion de Mono est fréquemment utilisée pour dire "Oui, .NET est multiplateforme". Quelle est la validité de cette réclamation? était que Mono n'est qu'une option IFF que vous développez contre!

Vous ne pouvez pas vous attendre à ce que les applications .NET fonctionnent hors de la boîte.


@Basic a dit que c'était plus un commentaire qu'une réponse. Pour être précis, je considère que c'est une question d'aller en tête de liste, car c'est peut-être la décision technique la plus importante que vous devez prendre lorsque vous traitez avec .NET. Comme le dit Basic, il testera contre Mono, alors c'est hors de propos, et je considérerais que Java et .NET sont tout aussi bien adaptés. J'ai très peu d'expérience avec .NET, mais pas mal en Java.

  • Performances - Java fonctionne plutôt bien, mais a encore un peu de temps de démarrage. En effet, une machine virtuelle Java démarre à zéro lors de son initialisation, et l'accès aléatoire au fichier jar de la bibliothèque d'exécution est plutôt lent lorsqu'il doit être lu à partir du disque. Les Java 6 récents ont un processus d'arrière-plan pour essayer de conserver les fichiers jar de la bibliothèque d'exécution dans le cache disque afin que l'accès soit rapide en cas de besoin.

  • Outils disponibles. De nombreux outils existent, et il y en a beaucoup disponibles en Open Source de haute qualité. IBM a des outils très avancés disponibles, mais ils prennent aussi beaucoup d'argent pour eux. Vous voudrez peut-être jeter un œil à MyEclipse qui gagne sa vie en assemblant les meilleures parties du monde Java et en les rendant accessibles à faible coût, pour voir ce qui est disponible. Netbeans a un très bon éditeur GUI. JDeveloper a un bon débogueur Swing. Le Sun 6 JDK a VisualVM qui est un profileur d'entrée de gamme agréable qui peut analyser les programmes déjà en cours d'exécution (ce qui est une fonctionnalité de tueur).

  • Compatibilité multiplateforme. Très bon, tendant à excellent. La JVM est très, très fiable et prévisible. Les problèmes n'apparaissent que lorsque des différences de système d'exploitation s'infiltrent, comme des séparateurs de fichiers, la sensibilité à la casse des noms de fichiers et le comportement des menus.

  • Bibliothèques. Il y en a beaucoup et beaucoup sont librement disponibles et utilisables, mais principalement écrits en Java car il est assez difficile d'extraire du code écrit dans des langages non JVM.

  • Coût. Java est essentiellement disponible gratuitement. Ce qu'Oracle indique, c'est que les outils électriques - provenant très probablement de JRocket - auront un coût. Notez également que le support étendu ("Java for Business") a également un prix. Les plates-formes non x86 sont en voie de disparition, mais IBM en a beaucoup et IBM fournit une excellente implémentation Java pour elles. Cela est considéré comme faisant partie du système d'exploitation - très probablement pour une meilleure adoption.

  • Processus de développement. Beaucoup de temps avec Java est consacré à la recherche et au choix de la technologie appropriée et à son apprentissage, mais quand cela est fait, je pense qu'il y a beaucoup de technologies qui sont assez rapides à développer. La dernière version de Java EE permet d'écrire des pages Web très puissantes à l'aide de Facelets qui peuvent être rechargées au moins aussi vite que les pages PHP.

Je pense que si vous n'êtes pas qualifiés ni dans Java ou .NET, vous allez gagner du temps et de l' argent en choisissant la technologie que vous et votre organisation sont les plus familiers.


14
Qui garantit que le programme Java que vous écrivez sur Windows s'exécutera ailleurs? Il suffit d'un seul appel JNI pour rompre cette garantie. Le même problème se pose avec la CLI - si vous utilisez une API de plate-forme non croisée, vous perdez la portabilité. Ainsi, la seule personne qui peut garantir la portabilité est vous-même - le programmeur, quel que soit le framework que vous utilisez.
Mark H

3
@ Thorbjørn, feriez-vous confiance à Oracle dans le climat actuel?
radekg

12
+1 parce Thorbjørn dit que si vous n'êtes pas engagé à 100% Windows que vous devriez aller avec Java, pas que vous devez aller avec Java. Et je suis d'accord - oui, Mono est là comme solution de rechange, mais si vos plans actuels ne sont pas validés pour Windows, épargnez-vous la peine et optez pour la technologie qui devait fonctionner sur d'autres plates-formes. Et je le dis en tant que développeur .NET et passionné .NET.
Carson63000

4
Je me demandais s'il y avait des électeurs "mono-existe-sur-d'autres" qui ont réellement essayé de le faire ...

4
"Java est fondamentalement disponible gratuitement (...) les outils électriques auront un coût (...) le support étendu a également un prix" . Exactement la même chose pour.NET, non?
Konamiman

19

OK, essayons de décomposer cela:

Prendre en compte:

Outils de performance disponibles (même des outils tiers)

Les plates-formes Java et .NET disposent de nombreux bons outils de test de performances, je sais que dans l'espace Java, il existe de nombreux outils open source gratuits qui conviennent à la plupart des scénarios. Je ne peux pas parler pour le côté .NET.

Compatibilité multiplateforme

Java a un avantage ici - le projet Mono (ou similaire) est requis pour faire fonctionner .NET sur certaines plates-formes. Je ne suis pas sûr que Mono soit à 100% à l'épreuve des balles et performant, quelque chose avec un peu de chance, quelqu'un d'autre peut y jouer.

Bibliothèques (en particulier les bibliothèques tierces)

Les deux ont un fort soutien ici. Au départ, l'écosystème Java ouvre la voie (il y a littéralement une bibliothèque open source gratuite pour à peu près tout ce que vous pourriez penser), mais je dirais que .NET a certainement rattrapé son retard (NHiberante pour la persistance, NUnit pour les tests unitaires pour en nommer deux de base + je suis sûr qu'il y a plus de chargement métrique).

Coût (Oracle semble essayer de monétiser Java)

Toutes les entreprises essaient de monétiser dans une certaine mesure, mais dans le cas de Java, je pense que votre déclaration est un peu trompeuse. Java était open source depuis la version 6 (le projet OpenJDK) et Oracle n'a montré aucune tendance à monétiser Java au-delà de ce que faisait Sun. Alors oui, ils vendent des serveurs d'applications et des extensions à la JVM (extensions de gestion en particulier), mais le noyau Java lui-même? Non et ils ne le feront jamais (cela a été déclaré publiquement de nombreuses fois).

Je pense que MS et Oracle bénéficient massivement en raison des revenus indirects avec leurs plates-formes répétitives.

Coût total de possession (TCO)? Je ne vais même pas entrer dans ce débat car il n'y a aucun moyen de le prouver (la programmation est une activité humaine créative après tout). Personnellement, je pense que les systèmes basés sur Java ont tendance à avoir un coût initial inférieur car vous pouvez utiliser une pile open source gratuite de haut en bas dans la plupart des cas. Cependant, les grandes entreprises ont tendance à préférer avoir des contrats de soutien, ce qui peut annuler cet avantage particulier.

Processus de développement (le plus simple / le plus rapide)

Cela dépend de ce que vous essayez de construire! Je dirais personnellement qu'ils sont à peu près égaux, bien que C # ait pour le moment quelques fonctionnalités supplémentaires dans le langage principal par rapport à Java. Cependant, avec plusieurs langages (interopérables avec Java) sur la machine virtuelle Java (Groovy, Scala, Clojure, etc.), vous pouvez avoir toutes les fonctionnalités de langauge souhaitées.

.NET avait un avantage distinct pour créer des `` trucs '' frontaux Web pendant un certain temps (développement rapide d'applications si vous voulez), mais je pense que JEE6 et / ou Spring et d'autres cadres Web / applications ont quasiment comblé cet écart.

Gardez également à l'esprit que Linux n'est pas votre plate-forme principale, mais vous souhaitez également porter votre projet sur Linux / MacOs. Vous devez certainement garder à l'esprit les problèmes qui ont tourné autour d'Oracle et de la communauté Java ainsi que les limites de Mono et Java. Il serait très apprécié que les personnes ayant une expérience des deux puissent donner un aperçu et leur propre opinion subjective sur lesquelles elles choisiraient et pourquoi.

Si vous voulez porter sur Linux, UNIX et en particulier Mac OS, comme indiqué ci-dessus, Java a un avantage.

J'espère que cela pourra aider!


4

Compte tenu de votre liste de points, je serais divisé et cela dépendrait vraiment de ce que je dois construire.

.Net gagne pour ces aspects:

  • Performance
  • Processus de développement (le plus simple / le plus rapide)

Java gagne pour ces aspects:

  • Compatibilité multiplateforme
  • Bibliothèques (en particulier les bibliothèques tierces)

C'est un tirage au sort pour ces aspects:

  • Coût (Oracle semble essayer de monétiser Java)
  • Outils disponibles (même des outils tiers)

.Net est, à toutes fins utiles, une pile technologique de plate-forme unique. Oui, il y a Mono, mais jusqu'à ce que Mono soit 100% compatible avec l'implémentation de Windows, il ne fournit pas une véritable expérience multiplateforme. Le seul sous-ensemble sur lequel vous pourriez compter pour la prise en charge multiplateforme est celui qui conviendrait à Silverlight.

Cela dit, .Net a une meilleure performance perçue (mesures réelles à déterminer). Aux yeux de l'utilisateur, la performance perçue est la seule chose qui compte. Après avoir développé en Java au cours des 12 dernières années et avoir fait récemment .Net, je peux apprécier la puissance de la plate-forme.

Java, d'autre part, a un ensemble d'IDE beaucoup plus riche à choisir, et le coût de ces IDE supérieurs est bien inférieur au coût de la variation .Net. D'un autre côté, le coût des moteurs J2EE professionnels éclipse facilement les coûts de l'environnement de développement. Dans .Net, j'ai la perception d'être nickle-and-dimed à mort. En Java, il existe des solutions de contournement aux coûts énormes - qui peuvent facilement être compensés avec le temps de développement des développeurs. En dehors de l'IDE, pour les outils qui comptent (profileur, couverture, etc.) les coûts sont égaux.

En fin de compte, cela dépend vraiment du besoin . Si je vais quand même déployer sur Windows, alors .Net est une évidence. J'ai des clients qui sont uniquement des magasins Windows. Si je suis en train de déployer sur Unix ou si j'ai besoin de prendre en charge des systèmes hétergènes, alors Java est une évidence. Je peux même être radical et suggérer une pile de technologies mixtes. Après tout, ce n'est pas parce que le client exige que le serveur soit Unix qu'ils l'exécutent sur leurs bureaux. Il n'est pas préférable de transformer chaque application en application Web.


4

Performance - Même

Les deux plates-formes fonctionnent extrêmement bien pour pratiquement toutes les applications.

Pas vraiment pour les différencier, bien que mon expérience subjective soit que Java a un léger avantage pour les applications de longue durée, tandis que .Net est plus rapide pour le démarrage des applications.

Outils disponibles (même des outils tiers) - Discutable

Cela dépend des outils dont vous avez besoin et de ce que vous connaissez.

.Net a certainement d'excellents outils fournis par Microsoft. D'autre part, il existe de bons outils dans le monde Java, par exemple dans les environnements Eclipse, Netbeans of IntelliJ.

Compatibilité multiplateforme - Java win

.Net est fondamentalement lié aux plates-formes Microsoft (Windows, Xbox, etc.). Les implémentations complètes ne sont disponibles pour aucune plate-forme non Microsoft .

Mono est sympa, mais il ne vous donne pas en fait une capacité multiplateforme complète car il ne prend pas en charge toutes les bibliothèques .Net (par exemple, vous ne pouvez pas vous attendre à ce que tous les éléments de l'interface graphique Windows fonctionnent correctement, donc à moins que vous ne passiez à une boîte à outils multiplateforme telle que GTK #, vous ne pourrez pas exécuter votre application sur différentes plates-formes)

Java est vraiment portable. Pas seulement le langage, mais plus important encore, toutes les bibliothèques Java sont portables. Si vous vous en tenez aux bibliothèques Java pures (par exemple Swing for GUI), votre code s'exécutera partout où vous disposerez d'un environnement d'exécution Java.

Bibliothèques (en particulier les bibliothèques tierces) - Java win

La meilleure force de la plate-forme Java est probablement le vaste écosystème de bibliothèques, en particulier les bibliothèques open source. Quelques exemples:

  • Toutes les bibliothèques et outils Apache
  • Toutes les bibliothèques du vaste écosystème Eclipse
  • Toutes les bibliothèques ont contribué / maintenu par Google
  • JBoss et tous les outils d'entreprise associés gérés par Red Hat

Coût (Oracle semble essayer de monétiser Java) - Java gagne si vous optez pour l' open source, sinon Even.

Vous pouvez avoir une pile Java 100% open source qui est gratuite et ne vous lie à aucune plate-forme propriétaire particulière. C'est 100% gratuit.

Alternativement, vous pouvez acheter IntelliJ IDEA, exécuter Java sur Windows et utiliser une base de données propriétaire, auquel cas c'est à peu près le même coût qu'une pile Microsoft .NET typique.

Processus de développement (le plus simple / le plus rapide) - Discutable

Cela dépend probablement plus de l'expérience de vos développeurs avec chaque plate-forme plutôt que de l'attribution particulière de la plate-forme.

.Net possède certainement d'excellents outils qui peuvent vous rendre très productif pour des applications GUI simples sur Windows. Pas étonnant car c'est le "sweet spot" pour le développement .Net.

D'un autre côté, je préfère la pile Java pour le développement côté serveur. Avec des outils comme Maven et toutes les capacités de déploiement / intégration continues, vous pouvez établir un processus de développement très efficace pour des applications robustes côté serveur.

C # en termes de langage présente certains avantages de productivité par rapport à Java. Mais d'un autre côté, si vous développez sur la plate-forme Java de nos jours, la tendance n'est pas d'utiliser Java lui-même, mais d'utiliser plutôt l'un des nouveaux langages JVM tels que Scala, Groovy ou Clojure - si vous le faites, vous serez beaucoup plus productif. que C # ou Java.


3

.Net

Il est difficile de répondre à cette question sans être subjectif ou incendiaire (j'ai le sentiment que je vais être rétrogradé), mais .Net est un langage à la hausse et Java semble embourbé par des problèmes juridiques et devient moins populaire.

De plus, .net est de nos jours un langage beaucoup plus cohérent et moderne avec un excellent support pour la programmation multicœur (Parallel.net) et asynchrone (extensions réactives), sans parler de LINQ sans lequel je ne pourrais pas vivre. .Net dispose également d'un certain nombre d'outils gratuits, mais Visual Studio Express, Sql Server Express, Web Matrix, etc.

Il est vrai que java possède certains avantages multiplateformes. Vous avez quelques options pour .Net avec mono, etc. qui pourraient être utiles pour les applications traditionnelles ou les composants backend, mais certaines sont douteuses si vous faites quelque chose de très spécialisé (et évitons de discuter de WPF).

Une autre option si la plateforme croisée est vraiment très importante est d'aller Silverlight, personnellement je ne suis pas très intéressé par les "applications" silverlight mais au moins ça marche.

Crossplatform est le point douloureux, demandez-vous si c'est vraiment vraiment nécessaire, au moins à ce stade.


Préférer .Net n'est pas une mauvaise chose. En fait, je l'aime bien. Il ne fait aucun doute que Java fait face à une crise d'identité en ce moment, ce qui est dommage - j'aime aussi cette plateforme. Je suis heureux que vous ayez reconnu l'amélioration des antécédents de Java en matière de multiplateforme (+1). Certains clients nécessitent un déploiement Unix, d'autres nécessitent un déploiement Windows. Les gens de Java peuvent desservir les deux plates-formes, tandis que .Net est vraiment limité à Windows. Cela dit, il y a beaucoup de clients Windows uniquement.
Berin Loritsch

1

Dans notre organisation, à ce stade, nous choisissons Java. La raison en est simple: notre équipe Java est plus grande, plus expérimentée et mieux outillée que notre équipe .NET (qui est également suffisamment liée à la maintenance des systèmes existants pour ne pas avoir les ressources nécessaires pour entreprendre de nouveaux projets majeurs) .
Cela dit, s'il y avait des raisons pressantes d'utiliser .NET (par exemple, les exigences des clients, certains clients peuvent avoir une grande base installée de logiciels .NET et veulent que leur nouveau système s'intègre dans cette base, prendre en charge la maintenance eux-mêmes, etc.), nous le faire et embaucher des entrepreneurs pour faire le travail où nous ne pouvons pas libérer notre propre peuple.
Je ne forcerais ni l'une ni l'autre des technologies sur un client contre leur intérêt supérieur, et certains clients bénéficient simplement (en raison de leur organisation interne) plus de l'un que de l'autre en raison des investissements nécessaires pour déployer le système (encore une fois, disons que nous avons un client qui a déjà a un certain nombre d'applications .NET en cours d'exécution et a le personnel pour les prendre en charge, nous n'allons pas essayer de les forcer à embaucher des gens et à acheter des licences matérielles et logicielles pour exécuter une application Java sur le côté, et bien sûr l'inverse serait Nous pourrions en fait leur conseiller de ne pas le faire s’ils venaient à nous avec cette demande).

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.