Developpez.com - Rubrique .NET

Le Club des Développeurs et IT Pro

Le débat fait toujours rage : Technologie .NET vs JAVA

Le 2002-09-03 14:45:35, par neo.51, Expert éminent
Bonjour,

Je sais que ce débat risque d'être trés animé.

On sait déjà tous que Java est gratuit + portable

et que tout ce qui est fait autours de DOTNET est parfois payant et pas forcément portable.

Quoique on peut noter que Mircrosoft à fait des effort en proposant Webmatrix : un outil de developpement gratuit pour faire des pages asp.net et je sais qu'il existe un outil de développement gratuit pour faire du C#. Pour ce qui est de la portabilité, on pourra d'ici quelques mois faire tourner des pages asp.net et des webservices sur un serveur sous LINUX.

Mais je préfèrerais élever le débat afin que vous me parliez plutôt des performances, de la sécurité et des différents avantages et inconvénients de chacun en faisant abstraction du prix des outils de développement.
  Discussion forum
1047 commentaires
  • Epictète
    Membre averti
    Ca me rapelle quand Microsoft a sorti son petit browser (Internet Explorer) face à Netscape. Retard insurmontable qu'ils disaient... tiens j'ai mal aux côtes rien que dit repenser...
    Microsoft à sorti un meilleur outil et l'à fait installer d'office sur tous les PC, netscape avait aucune chance. Maintenant ca va être plus dur d'installer .NET sur tous les serveurs Linux. D'ailleurs c'est plus dur (cf article de Bill qui déclare -> ."net ca démarre pas"

    Ca empèche pas que .NET c'est une bonne idée et une bonne technologie.

    Si t'avais un choix à faire tu peux tenter (si il est sorti) le J# qui est un mix de Java sur plateforme .NET. Là j'attends la levée de boucliers...
    Comme tu le sait très bien et pour cause, il semble que la majorité des développeurs "sérieux" pour .NET se lancent plutot dans C#, qui est le langage spécialement créé pour .NET.

    Si tu parles de J#, je supose que c'est pour créer une sorte d'"animation" sur ce sujet sur le forum. Je vais même pas répondre... Parce que je m'en fou de J#, comme tout le monde... Ah si j'ai trouvé ! J# à tous les inconvénients liés à .net sans avoir aucun des avantages de Java.

  • B.AF
    Membre chevronné
    Le problème de la gratuité, c'est quand tu fais du gratuit :
    - Tu te tapes 72000 fois les mêmes questions qui sont dans la doc, dans le forum que tu héberges gracieusement, mais dont les charmants utilisateurs n'ont que faire
    - Tu te tapes les remarques de grand guignol, chef de projet dans une PRESTIGIEUSE banque ou dans un IMPORTANT cabinet qui t'explique que l'absence de spécifications ou de roadmap empêche la brique de devenir un "élément stratégique" de l'architecture (sic)
    - Tu te tapes Kevin 20 ans, sort de l'école, t'expliques comment si tu avais appliqué le design pattern trucmuche de Fowler, tu aurais un meilleur framework
    - Tu te tapes ceux qui font la même chose commercialement et qui te tape allégrement dessus
    - JAMAIS un utilisateur qui forke ton truc n'en fera bénéficier les autres
    - JAMAIS un utilisateur ne s'est spontanément proposé de payer pour le support

    Et après tu as 4500 framework demi-morts / pas finis comme en Java.

    Moi je trouve en 2011 que le payant source ouverte est la meilleure solution, au moins elle est claire et précise.
  • _skip
    Expert éminent
    On s'en sort assez bien avec un pack MSDN pour le dév. Mais soit. Dans l'absolu ton environnement de travail est plus cher (quoique même si je fais du java, j'utilise du payant). Mais ça c'est une fraction bien souvent infime de ton coût de développement. Sans compter que le projet et son destinataire fixe bien souvent à lui seul le choix de windows ou linux.

    Si tu gagnes 2-3 jours de dév avec un outil spécifique, tu as amorti ton investissement. J'oublie très rapidement les 1000$ de la souscription Telerik ou DevExpress si ça m'évite d'aller me faire chier avec Swing et JasperReport ou Birt.

    Pour ce qui est de négocier avec les fournisseurs, tu vas sûrement pouvoir me sortir un ou 2 cas d'exception, mais à moins que tu représentes un potentiel de vente important tu risques de pas toujours être écouté. En tout cas je compterai pas trop là dessus. Je préfère écarter cette possibilité tout de suite que de tenter le diable et devoir compter dessus.

    Enfin, tout ça c'est de la gestion de risque, ce que je voulais dire surtout, c'est que peu importe ce qu'on choisit, gratuit, open source ou payant, on finit quand même par dépendre de pas mal de monde. A travers non seulement le langage que tu utilises mais toutes les librairies et frameworks dont tu comptes te servir.
  • B.AF
    Membre chevronné
    Envoyé par sinok
    Ca n'en prends pas la direction, les JSR 295/296 (bindings et application framework) ont été un poil fossoyées. Il y aura probablement quelques composants d'ajoutés comme une DatePicker (enfin....) et le JXLayer qui permet pas mal de chose niveau graphique/bloquage des composants.
    Le même avec Binding en .Net et en....2003...

    Je ne sais pas où va Java, mais là j'arrête de suivre. Même les plus belles histoires doivent avoir une fin..
    Java avec ses JSR, sa communauté, son évolution au ralenti, ses 52351 frameworks; c'est la victoire de la technocratie sur le savoir faire.
  • cs_ntd
    Membre éprouvé
    Envoyé par h2s84
    A lire et à commenter ce billet d'un CEO expliquant pourquoi ils n'ont pas voulu embauché un développeur .Net.
    Cet article est un torchon, visiblement écris par une personne remplise de préjugée et d'idée préconcues sur une plateforme qu'elle ne connait pas.

    Il n'y a qu'a voir les commentaires a la fin. L'auteur avoue lui-meme qu'environ 85% des gens ne sont pas d'accord avec lui...

    Pour les gens qui chercherait a comparer un langage vs .NET, ne surtout pas croire un mot de cet article... N'importe quoi d'autre est préférable...
  • Epictète
    Membre averti
    C'est pas très original, on en parles entre nous..., ca arrive meme qu'on s'envoi des rapports "interne" par emails.

    Du coté des publiés il y à quand même des choses, bien que cela ne concerne que les serveurs d'applications Java, on peut y apprendre des choses :
    http://www.cmis.csiro.au/ADSaT/PDF/M...20Summary1.pdf

    En fonctionnalité/Maturité/sécurité, il n'y à pas (encore?) l'équivalent en .NET de Weblogic, websphère, Borland Appserver...

    Déjà, il faudrait que tu puisses choisir ton serveur d'applications pour .NET pour commencer... pour avoir le droit de prendre le meilleur...



    PS : Je suis pour Java et pour .NET, parce que je suis surtout pour la concurrence, c'est indispensable pour nous tous pour que nous ayons un choix possible...
  • _skip
    Expert éminent
    Envoyé par alex61
    le problème c'est que toute les boite ne sont pas daccord pour payer ce genre de chose
    Je sais j'ai bossé pour ce type de gens. Leur problème en général, c'est qu'ils pensent que si on peut le faire soi-même alors c'est gratuit. Suffit de voir combien coûte une journée développeur à l'entreprise puis on comprend mieux l'intérêt de payer des petits montants pour des trucs supportés et documentés, parfois même des gros.
  • B.AF
    Membre chevronné
    Il y a les mêmes côté .Net.

    Maintenant peut être juste faire la différence entre ...
    Ce qui est du framework
    Ce qui est du tooling
    Ce qui est de la librairie tiers.

    Voir JNDI, Strut ou même J2EE, c'est quand même n'importe quoi ; il y a les choux, les carottes et les poires....

    Surtout que Spring existe en .Net; Quartz existe en .Net (Et dans le framework il y a largement ce qu'il faut aussi);NMS existe mais le framework a sa propre api de messaging et wcf aussi, il n'y a pas J2EE car il n'y a pas de dissociation,pour JNDI il n'existe pas explicitement, mais il y a des librairies équivalentes (Linq to AD par exemple). Il n'y a pas Terracotta, mais il y a Esent en code managé, appfabric en cache distribué et clustering de services; et quelle serait l'utilité de struts en .Net (Le portage était fait, personne n'en voulait..)?

    Quand à plus riche, oui, il y a de façon évidente un nombre de frameworks tiers plus important, mais ce n'est pas un bien. Beaucoup sont inachevés, incompatibles les uns avec les autres.

    Pour la richesse...Dis moi simplement ce que tu as besoin de faire côté serveur en Java qui soit concret et qui ne soit pas possible en .Net ? (Et sans passer par des librairies externes.)

    Faut peut être aussi te dire que si ça n'existe pas c'est aussi parce que le besoin n'est pas là. Et ça n'empêche pas des applications .Net très poussées de fonctionner tous les jours.

  • davcha
    Membre expérimenté
    Envoyé par B.AF
    Comme je le pense, Linq devient pour bcp de dev une finalité en soi (on se fout de ce qu'on modélise, on fera du linq); les epxressions lambda et les génériques à trop forte dose ça réduit la fiabilité de l'application et non ça n'améliore la lisibilité d'avoir des chaines de lambdas.

    Pareil pour les extensions; c'est sympa, sauf quand on étend une méthode qui finalement n'est pas si générale et provoque des petites failles...
    C'est pas des arguments contre .NET ou C#, ça, ce sont des arguments contre les développeurs qui font n'importe quoi.
  • Logan Mauzaize
    Rédacteur/Modérateur
    Envoyé par SQLpro
    Linux est gratuit, mais plus couteux en admin...
    Pour avoir travaillé avec un spécialiste Windows, je peux te dire qu'il y a un certain nombre d'opération sous Windows qui nécessitent des interventions manuelles (non scriptable) et du coup quand tu dois réaliser l'opération sur un parc de serveur, le coût devient astronomique.

    Après je n'ai pas les connaissances suffisantes pour affirmer dans l’absolu que l'un ou l'autre coûte plus cher en administration. Mais j'ai quand même le sentiment qu'il y a plus d'admin spécialiste Linux que Windows (auto formation sous Linux, les entreprises recherchent surement en priorité des ceritifiés pour les environnements Windows, manque d'accessibilité aux serveurs Windows, etc.)

    Envoyé par SQLpro
    Le débat sur la facilité/qualité du langage est luis aussi stérile les deux étant à peu près au même niveau de version en version.
    Le débat sur le cohérence est plus intéressant, mais reste mineur... Certes MS est plus cohérent, mais réserve quelques lacunes. Java l'est sans doute moins, mais avec un offre plus diversifié car plus ancienne.
    Plutôt d'accord

    Envoyé par SQLpro
    Non, pour moi, la vrai différence, essentielle, réside dans l'aspect "managé" du code.
    D'un côté (.net) on dispose d'outils natif pour savoir en "live" comment le code se comporte... De l'autre c'est beaucoup moins évident.
    Je connais pas les capacités de .net mais pour Java les outils ne manquent pas : dump mémoire (Java ou natif), dump thread (Java ou natif), décompilation du code, monitoring/paramétrage de TOUTES l'activité de la VM (GC, JIT, etc.), le tout en local mais aussi en distant. Sans compter le support de protocole de monitoring. Et le tout très aisément scriptable (pour réaliser des opérations automatiques de surveillance ou de diagnostic).
    Et ce depuis au moins la version 1.4 (20002002), soit au moins deux ans avantdepuis aussi longtemps que la sortie de la première version de .Net

    Envoyé par SQLpro
    Un exemple en pratique : SQL Server intègre une machine .net indépendante de la machine .net de l'OS, permettant de développer des routines SQL sous codage .net. Lorsque ces routines (procédures stockées, fonctions, types objets...) sont exécutées par SQL c'est sous le contrôle de SQL Server qui audite en permanence sa machine .net appelée SQL CLR. En cas de mauvaise conduite (par exemple une fonction récursive qui vampiriserait la mémoire) alors SQL Server peut décider de tuer les threads fautifs, afin de préserver la stabilité du serveur SQL...
    Cela n'existe pas à ma connaissance dans la machine Java !
    Pourquoi comparer Java avec SQL Server ?
    Tu peux coder en Java sous Oracle DB si ca te fait plaisir. Celui-ci embarque aussi sa propre VM (voir plusieurs).
    Pour le reste c'est applicatif. D'ailleurs un thread n'a pas de heap qui lui est propre, donc on peut simplement contrôler la taille de sa stack.

    EDIT : Oups, erreur sur les dates de sortie de Java 1.4