J2EE vs .NET, le retour
Je m'offre un billet d'humeur.
Dans le journalisme, on appelle ca un "maronnier", parce que ca refleurit chaque saison, un peu comme l'article annuel du Point sur le réseau de la Franc Maçonnerie. Ca fait toujours monter l'audience.
Le débat "J2EE vs .NET" resurgit donc périodiquement.
Personnellement, IMHO, il y a de grandes différences entre J2EE et .NET
- J2EE est une énorme librairie de classes au point qu'un faut plusieurs mois pour tout connaître, tandis que .NET est très différent : c'est une énorme librairie de classe au point qu'un faut plusieurs mois pour tout connaître
- Java est un langage objet où les objets sont tous dynamiques avec une machine virtuelle (JRE) munie d'un garbage collector pour supprimer les objets déréférencés par erreurs, tandis que C# est très différent : c'est un langage objet où les objets sont tous dynamiques avec une machine virtuelle (CLR) munie d'un garbage collector pour supprimer les objets déréférencés par erreurs
- [après, je n'ai plus le temps]
Bon, il y a quand même une vraie différence : .NET est propriétaire (vous êtes obligés d'utiliser un serveur Microsoft) tandis que JAVA ne l'est pas (vous pouvez utiliser un serveur quelconque (mais ca marche plus vite avec un serveur SUN optimisé pour JAVA !) A mon avis c'est la seule.
Au final, pendant que vous passez des mois et des mois à vous demander lequel des deux solutions est la mieux, les applications métiers sont
- toujours aussi mal faites,
- aussi peu alignées sur les besoins des clients, sur les métiers,
- sur la stratégie,
- en retard, etc.
L'eau qui sont du tuyau n'est pas potable, mais les partisans du match "J2EE vs .NET" passent du temps à savoir s'il vaut mieux un tuyau en plastique ou en PVC.
Il y a quand même du vrai, non ?
Christophe Thiry
PS : Ce blog s'efforce de rester dans la limite des choses que l'on peut dire publiquement sans révéler de "secrets de fabrication" : expliquer les concepts, les démarches, leur utilité ... et n'a pas pour but de porter préjudice à la profession.
posted by Christophe Thiry @ 5/16/2006
21 Comments:
Chose très amusante, au moment de lire ce billet, quelques minutes plutôt, je venais de terminer la revue de code de ce qui est censé devenir le cadre de référence pour toutes les applications futures d’une très grande institution française. Il se trouve que c’est écrit en Java mais ça aurait aussi bien pu l’être en langage Q (langage quelconque). J'arrive encore une fois, comme trop souvent, à la même conclusion: Quelque soit le tuyau utilisé, l’eau qui le traverse dégagera toujours la même odeur nauséabonde…
Sur le fond, je suis bien d'accord, J2EE et .NET sont techniquement très comparables et des activités plus orientées métier que technique sont tout aussi essentielles à la réussite d'un projet.
Mais, en ce qui me concerne, le facteur primordial n'est pas abordé : le facteur humain. Quand, par exemple, on doit choisir entre l'embauche d'un diplomé récent qui, statistiquement, ne jure que par java ou le recyclage d'un développeur VB qui aura un peu de mal à passer de visual studio à eclipse alors là, oui, le débat "J2EE vs .NET" prend tout son sens !
Pour rester sur l'analogie, le plus important, c'est celui qui tient le tuyau et la façon dont il sait le tenir. Si le plastique lui donne des rougeurs aux mains, alors prenons en un en PVC.
Une remarque en passant : c'est java qui est propriétaire (Sun) et .NET qui ne l'est pas (normalisation ECMA, implémentation open-source Mono, ...)
Merci pour ces commentaires :-))
"le facteur humain"
En général, on embauche qqn qui doitavoir la bonne compétence et s'intégrer dans l'équipe en place. Sauf erreur, je n'ai jamais vu de cas où le profil du développeur qu'on embauche conditionne le choix ultérieur de l'outil ... Ou alors j'ai mal compris ta remarque.
"java est propriétaire" Merci pour cette précision. Cependant, je croyais qu'avec .NET on était pied et poing lié à Microsoft (obligation de mettre IEE sur le serveur par exemple) Si ce n'est plus le cas, alors J2EE et .NET deviennent strictement équivalents ! Est-ce que l'implémentation Open Source Mono est aussi bien que celle de Microsoft ?
Tout à fait d'accord : quand on a déjà fait certains choix techniques, on embauche quelqu'un qui correspond à un profil recherché. Mais avant de faire ces choix, on peut être 'guidé' par une situation existante : une équipe en place, une plus grande facilité à transférer du personnel en interne que de faire une nouvelle embauche...
Pour ce qui est de la qualité de Mono, je suis loin d'être un spécialiste mais je me souviens d'avoir lu qu'il était encore très en deça des performances d'un .NET Microsoft ou d'un J2EE.
On se demande ce que des considérations de "developpeur ras-les-paquerettes" viennent faire sur un blog censé parler d'urbanisation !!
C'est vrai, j'aime bien déborder du cadre! Surtout pour faire enrager mes collègues.
Le fait que je fasse de l'urba ne me dispense pas d'avoir une opinion sur les sujets connexes et le monde de l'informatique en général.
De plus le sujet est plutôt un thème d'architecte technique que de développeur à proprement parler.
Merci néanmoins pour le commentaire.
Le prochain billet sera consacré 100% à l'urbanisation, c'est promis.
Mr Anonymous, ce n'est pas avec de telles remarques que vous arriverez à intéresser le clan des paquerettes à vos réflexions mésophériques sur les problématiques d'urbanisation. Ce n'est d'ailleurs peut être même pas dans vos intentions ?
Cher Oaz,
Ne dit pas trop de mal des anonymes, il y a quand même du bon dans cette remarque ... Elle montre bien le décalage que certains vivent en plaçant d'un côté "ceux qui font des choses concrètes" et "ceux qui pensent mais qui ne font rien de concret". C'est un peu la version moderne des cols blancs et des cols bleus.
Autant dire que je m'élève contre cette idée.
Je suis moi même ex-développeur (fana d'orientation objet et de C++, à l'époque) Le temps que j'ai passé à faire du développement était vraiment intéressant. Je suis allé au bout du bout du domaine. Je n'ai aucun mépris pour le développement.
De plus, l'urbanisation du SI, croyez moi, ce ne sont pas "de belles idées inapplicables", comme on l'entend trop souvent, c'est concret, c'est quelquefois "ras les pâquerettes".
Ceci dit, Mr l'Anonyme, ce serait bien sympa si vous signiez avec vos initiales...
N'étant moi-même que ex-développeur et absolument pas urbaniste, je me garderai bien de prendre parti. Je voulais juste faire remarquer l'incongruité de la remarque.
Ceci étant dit, dans un billet d'humeur, il ne faut pas s'étonner d'avoir des commentaires d'humeur :-)
.Net n'est pas propriétaire. Seul Vb.Net est propriétaire. Voir Ecma. Voir Mono.
Je trouve affligeant de lire que .net ne serait pas propriétaire car "normalisé" à l'ECMA.
Extrait de la ECMA-334 "CLI is based on a subset of the
.NET Framework" ... CQDF. (Je vous au passage à lire la liste des contributeurs de l'ECMA-335 qui définit la CLI, il y a une surprise).
Faire croire que .net n'est que la somme des choses spécifiés à l'ECMA est tout aussi ridicule que faire croire que mono est équivalent à .net (ou même compatible .net).
Je rappelle que si je construit une appli mono, il y a de grande chance quelle tourne sous .net (compte tenue du peu de recul et de l'abscense de test de compatibilité par l'ECMA ou MS, aucune certitude n'est à ce jour de mise). Par contre, faire tourner une application réelle .net sous mono est tout aussi aléatoire que de tenter de lancer office sous winehq. Je doute que quiconque dans le monde des entreprises base sa confiance sur des "probabilité de succès", c'est la raison du succès trés mitigé de mono.
Enfin, Java n'est pas propriétaire mais la spécification des JSR de Java est sous controle de Sun. Il y a une grosse différence. Ainsi, toutes les spécifications de Java sont disponible publiquement et il est possible à n'importe qui des les implémenter sans en référer à Sun ou un autre membre de la JSR en question. Pour utiliser le nom Java, il suffira ensuite de passer le TCK (test de compatibilité) correspondant à la JSR sur son implémentation pour obtenir de facto le droit de prétendre à être compatible Java ! Ainsi, Microsoft pourrait très bien continuer sa JVM et la mettre compatible Java SE 6 sans aucune difficulté, ni aucune représaille juridique possible de quiconque tant qu'ils passent le TCK.
Dans .net, c'est trés différent. Microsot fait les specifications et ne les publies pas. Seul la partie centrale de la plateforme verra ces spécifications publiées via le processus de l'ECMA.
Personellement, je ne suis pas sûr de savoir lequel des deux est plus libre pour ce qui est de la possibilité d'un quidam d'introduire des changements dans la plateforme.
Enfin, un peu d'histoire. Je pense que tout le monde ici est conscient que .net n'a été créé que pour des raison stratégiques (pour ceux n'ayant pas suivit cet épisode, je vous invite à surfer sur archive.org dans les années 1998 autour de jview et visual j++).
On rapellera également l'opposition du délégué américain (ayant des liens avec une célèbre société de seatle) lors du passage de Java 1.1 devant le commité de l'ISO avec pour but une normalisation intégrale. Je passerai également la tentative de normalisation avorté à l'ECMA ... heureusement quelques années plus tard une plateforme "révolutionaire" aller naître ;-) Toute révolution est toujours relative ...DNA,VB,MFC RIP.
Merci pour toutes ces précisions.
Cependant, je trouve à mon tour affligeant que ce soit ce seul type de discussion qui fasse réagir les internautes versés sur l'architecture applicative.
Comme a chaque fois, on en reviens toujours à des discussions de technos (est ce que .NET et mono c'est la même chose ou pas) alors que c'est arrivé comme ca dans le débat mais ce n'est pas le plus important.
Que la question de fond ne semble curieusement intéresser personne : tout ce qui tourne autour de l'(in)adaptation des applications au métier.
Voir le contenu initial du billet.
C'est vrai que ce genre de post font toujours réagir...et ce n'est pas près de s'arréter. Je suis globalement d'accord sur le contenu surtout que selon moi le vrai problème n'est effectivement pas là (J2EE ou .Net). Quand je vois les commentaires sur le billet, je pense qu'il faut effectivement recruter suivant les compétences recherchée pour le projet ... mais avant tout prendre quelqu'un qui soit bon indépendament du language/environement: un mauvais développeur le sera en C# et en Java. J'entends souvent certaines personnes (dont des VP R&D) qui considèrent que la grande force du Java, c'est déviter aux développeurs d'écrire du mauvais code...c'est affligeant d'incrédulité. Ce qui m'inquiète plus encore est le fait de voir le niveau général des formations en informatique baisser d'année en année. Je vais peut-être passé pour un ringard mais pour prendre u_n exemple extrême: savoir trier une liste simplement chainée est plus important que de connaitre les api .Net pour construire un objet XML.
Magnifique des Urbanistes qui parlent. Quand vous aurez finit de traîter les développeurs comme de la viande, vous prévenez.
Il n'est ni moins ni plus noble de développer que de participer aux autres phases d'un projet.
Pour en revenir au sujet à proprement parler. Vous êtes totalement à côté de la plaque. Mais au vu de votre niveau technique, cela ne m'étonne guère.
La réelle différence entre .NET et Java c'est l'eco-système qui est disponible. En .NET il n'y a rien alors qu'en Java l'eco-système est complet, mature et en évolution rapide. Cela est possible en grande partie grâce à la communauté open source qui contribue pour beaucoup à l'amélioration des frameworks et des socles, et qui innove pour faire vivre une techno.
Le langage n'est rien. Seul compte l'existant qui gravite autour.
Petit remarque pour Mickaël Sauvée: Vous êtes en effet ringard, il y a belle lurette qu'on ne se soucis plus de trier une liste chaînée ou tout autre chose du même style. Pour cela il existe des algos tout prêts et mieux fait que ce que 99% des développeurs feraient ainsi que des framework qui permettent aujourd'hui de ne se concentrer que sur la logique métier et les besoins du client.
D'une manière générale, le niveau en informatique ne baisse pas encore faut-il savoir récruter correctement.
Pour finir j'ajouterai que la certification ECMA c'est du vent. Le seul langage libre des deux est Java qui est desormais open source.
Cher Waddle,
Croyez moi ou non, je n'ai aucunement l'intention de traiter les développeurs "comme de la viande". Je l'ai été moi même à une certaine époque où j'étais expert en C++, et je n'ai aucune arrière pensée de cette nature.
De plus je ne vois pas à quelle phrase vous faites allusion ! Donnez-la moi !
En tout cas, le sujet génère encore des polémiques et de l'humeur, de mon temps c'était Pascal vs Langage C :-)
Merci pour votre contribution.
Je rejoins ce que dit waddle. La différence entre Java et .Net ce n’est ni le langage ni le framework mais la richesse de l’éco-système qui les entours : composants de technique de plus ou moins au niveau, framework de persistance, d’IOC, gestion de configuration, Esb, etc. Dans ce domaine Java est gagnant. Les avantages : gain de productivité, coût moindre (licence) . On ne réinvente pas la roue. Et on peut venir avec un « stack » de construction d’application prêt à l’emploi et éprouvée (ex : JSF/Spring/Hibernate). Le passage en GPL du JDK ne peut qu’accélérer l’avantage de Java en ce domaine. Côté .Net il y a quelques efforts louables (Spring .NET, Linq) mais on est loin de Java. La qualité des applications .NET et leur robustesse en terme d’adaptation au changement s’en ressent
Est-ce que par hasard quelqu'un se souvient de l'intérêt du métier ? Est-ce qu'il consiste à faire mumuse avec les derniers jouets technologiques du marché ou bien de répondre à des exigences métiers ?
Au finalement qu'est-ce que les utilisateurs nous demandes ? Un truc qui marche !... La technique il s'en tamponne joyeusement !
Alors, nous qui sommes pétri de bon sens (sinon on ne serait pas à ces postes là) qu'elles sont les réponses que nous devons leur apporter ?
1 - De quoi disposent-ils ? Il ne sert à rien de générer des tempêtes dans verre d'eau, si le client est full Microsoft direction .Net, s'il est full Unix direction Java
2 - Que veulent-ils ? Question beaucoup plus pernicieuse qu'il y paraît ! Réduction du TOC ? (allons vers java) Uniformisation des plateformes ? (laquelle et pourquoi ?)
3 - Pourquoi le veulent-ils ? On en arrive à questions quasi existentielles ! Simple marotte du nouveau Chef du service informatique qui veut marquer son passage avec des perspectives radicalement innovantes par rapport à son prédécesseur ?!
Cela fait maintenant 10 ans de que je traîne mes guêtres dans le monde merveilleux de Java, et pourtant je donne des architectures full Microsoft (.Net, Share Point, SQL Server, Report services, Analysis services, en bref toute l'armada Microsoft). Pourquoi ? Parce que le parc logiciel est constitué majoritairement d'appli dans cette techno.
Alors revenons un peu sur terre : toutes les technos sont bonnes quand les applis sont correctement architecturées et codées.
La techno ne sert à rien si elle n'implémente pas un fonctionnel bien cadré. Et les utilisateurs continueront de raller tant que l'on fera de la techno pour faire de la techno.
En bref, ce débat Java vs .Net était, est, et sera toujours stérile tant que nous oublions que la technique est au service du fonctionnel et des désidératas du client…
Il est regrettable que l'analyse et le devoir de conseil d'un urbaniste deviennent les œillères d'une bête de bat tentant de porter SA techno vaille que vaille…
Cher Conciliateur,
"En bref, ce débat Java vs .Net était, est, et sera toujours stérile tant que nous oublions que la technique est au service du fonctionnel et des désidératas du client…"
Je suis 10000% d'accord !
C'est pourquoi, ce genre de débat m'amuse toujours autant.
La normalisation Ecma voulue par Microsoft permet aujourd'hui de faire du C# sous Linux avec Mono et Gtk.
Les applications me semblent toujours plus véloces sous .Net et les environnements de développement toujours plus aboutis, magré NetBeans pour Java.
La montée en charge que j'ai pu observer depuis deux ans autour des solutions .Net amène un grignotage des "parts de marché" Java et notamment J2EE.
Il ne faut pa oublier la montée en puissance du Php, des Cms et des Frameworks qui l'entourent : Symfony, Cake, Zend.
http://dszalkowski.free.fr/dotclear/index.php?2007/04/06/1816-stats-php-sur-internet
tu dois vraiment rien connaître, ni à J2EE, ni à .NET pour sortir des betises aussi grosse que ca!
Je suis émerveillé par la profondeur de ton argumentation.
Si tu nous expliquais un peu pourquoi tu penses que j'ai dit des bêtises ... monsieur le juge
CT
Enregistrer un commentaire
Links to this post:
Créer un lien
<< Home