[Débat] Technologie .NET vs JAVA

Version imprimable

Voir 40 message(s) de cette discussion en une page

03/09/2002, 14h45
neo.51

[Débat] Technologie .NET vs JAVA

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.
03/09/2002, 15h59
Epictète

Il y a aussi une différence coté hébergement.

.NET est hébergé exclusivement sous Windows. Hors Linux et Unix détiennent plus de 2/3 des installations de serveurs. Donc actuellement .NET en tant que serveur (dans ta comparaison à Java) ne s'adresse qu'à 1/3 du marché actuel, grand maximum.

Par contre en effet du coté des stations clientes, Microsoft détient l'avantage puisque Microsoft détient les clef de windows.
03/09/2002, 16h05
neo.51

Citation:

Envoyé par Epictète

Il y a aussi une différence coté hébergement.
.NET est hébergé exclusivement sous Windows. Hors Linux et Unix détiennent plus de 2/3 des installations de serveurs.

Apparemment il y a un projet sur sourceforge :

http://sourceforge.net/projects/dotnetwebserver/

Donc ça peut changer :wink: . Je souhaiterais avoir votre avis au niveau de la facilité de développement, de déploiement et sur les performances.
03/09/2002, 16h34
VisualCBien

Citation:

.NET est hébergé exclusivement sous Windows. Hors Linux et Unix détiennent plus de 2/3 des installations de serveurs.

Ca me rapelle quand Microsoft a sorti son petit browser (Internet Explorer) face à Netscape. Retard insurmontable qu'ils disaient... tiens j'ai mal aux cotes rien que dit repenser...
Ca tourne vite l'informatique. Pareil pour Java. Tout le monde se demandait ce qu'un clone de C++ venait faire dans ce marasme. Et il sait finalement bien imposé.
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...
03/09/2002, 16h58
Epictète

Citation:

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.

Citation:

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.

:lol:
03/09/2002, 16h59
draken

Je ne connait pas particulierement bien .NET donc je ne peux pas parler des performances.

Pour moi JAVA et notament J2EE offre l'avantage majeur d'être un chouchou de la communauté Open Source. Donc on dispose d'outils et d'api rigoureuses et sans bug (car des qu'ils sont detectés ils sont corrigés).
De plus J2EE en terme de dévelopement offre un éventail énorme en terme de possibilités pour les entreprises.
03/09/2002, 17h09
VisualCBien

Citation:

Si tu parle de J#, je supose que c'est pour créer une "animation" 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.

Bah non même pas ... Sortir J# face à C#, c'est sûrement occuper les developpeurs chez Microsoft. Le seul avantage c'est la conversion de J++ vers J#. Mais là une autre question me turlupine : Qui utilisait J++ ?
03/09/2002, 17h20
Epictète

Citation:

Envoyé par VisualCBien

Bah non même pas ... Sortir J# face à C#, c'est sûrement occuper les développeurs chez Microsoft. Le seul avantage c'est la conversion de J++ vers J#.

Bonne analyse...

Citation:

Envoyé par VisualCBien

Mais là une autre question me turlupine : Qui utilisait J++ ?

Pas mal de personnes qui avait Visual Studio, avec J++ inside. D'ailleurs J++ était un très bon outil , mais qui est tombé en désuétude quand MS à décidé de l'abandonner volontairement pour faire C# à la place, sur lequel il avait le contrôle sans avoir besoin de SUN.
03/09/2002, 18h44
fd

c#

Je ne vais pas répondre sur l'archi .NET car je ne l'ai pas pratiqué.
Mais il faut se méfier de la force de vente de Microsoft (rappellez vous Windows avant la 3.0 ...)

Par contre C# m'a l'air d'un bon langage.
C'est proche de Java mais avec des améliorations notable :

Possibilité de compilation conditionnelle,
d'utiliser des pointeurs (dans du code "unsafe")

C'est un mix de Java, de C++ avec des touches de Delphi
03/09/2002, 20h16
RDM

Re: [Débat] Technologie .NET vs JAVA

Citation:

Envoyé par neo.51

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

et que tout ce qui est fait autourd de DOTNET est payant et pas portable.

J'aimerais bien que tu développes les points ci-dessus
en quoi Java est gratuit et .NET ne l'est pas ?

Portabilité: Tu fais tourné des applis .NET sur des pocket PC comme sous des PC sous windows, bientôt sous linux...
04/09/2002, 09h49
olrt

Le problème avec Microsoft c'est qu'il faut suivre Microsoft dans ses
évolutions technologiques et ça coûte cher.
Regardez le fossé entre Visual Studio 6 et Visual Studio .NET,
entre Windows 3.1 et Windows 2000 ...
Si on veut mal conseiller une entreprise on lui dit : "Achetez du Microsoft et allez y à fond les manettes."

Si on veut bien conseiller une entreprise on lui dit : "Voici les avantages/inconvénients de JAVA/J2EE et .NET.
Maintenant faîtes votre choix en votre âme et conscience."
04/09/2002, 09h55
Epictète

Tout à fait, se pose la question de la dépendance complète à Microsoft.

En Java, tu peux choisir l'OS du serveur : Linux, Windows, Unix, .., tu peux choisir le serveur d'applications : Tomcat (Libre) ou BEA, IBM, Borland, etc..., tu peux choisir l'outil de développement, Borland, IBM, SUN, etc...

Bref tu as un choix énorme, sur une plateforme totalement mature, et en même temps en évolution.

Sans parler des nombreux outils additionnels comme par exemple les optimiseurs de code Java (optimize it, jprobe, ...), etc...

Enfin certaines technologies avancées des serveurs d'applications Java n'ont pas encore leur équivalents en .net, comme par exemple les EJBsessions, etc...
04/09/2002, 11h19
neo.51

Citation:

Envoyé par Epictète

Enfin certaines technologies avancées des serveurs d'applications Java n'ont pas encore leur équivalents en .net, comme par exemple les EJBsessions, etc...

Peux tu détailler le point ci dessus car en fait c'est ça qui m'intéresse le plus : savoir ce que tu peux faire en JAVA, mais pas en .NET et réciproquement.
04/09/2002, 13h47
olrt

En JAVA il y a :

Les EJB session (statefull ou stateless)
Les EJB entity

En .NET il y a les serviced components :

Stateless ou statefull mais Microsoft pousse au stateless
(composants déconnectés) pour plus de perfs.

Ce qui est nul avec les EJB :
Tu dois définir une interface home et remote pour un EJB
(la home c'est pour l'appeler depuis la même JVM et la remote
c'est pour l'appeler par RMI).

Ce qui est bien avec les Microsoft serviced components :
C'est la même interface que le composants soient in-process ou remote.

Merci d'ajouter des commentaires techniques sur les différences
entre les deux technos.
05/09/2002, 13h34
Traroth

Le problème de la fiabilité me parait fondamental

On peut tourner longtemps autout du pot, concernant les fonctionnalités des produits. Là, il me semble que .NET partant avec 7 ans de retard sur Java, il est logique que la plateforme ait du retard. Mais ca, ca se rattrape.
Ce qui me semble le plus fondamental, c'est le problème de la fiabilité, en terme de securité, de performance, de disponibilité et d'encombrement, pour le système lui-meme, comme pour les applications qu'on réalise avec.
Et là, franchement, Microsoft a tout à prouver. Non seulement, ils ont vraiment mauvaise reputation dans ce domaine, mais les premiers problèmes avec .NET sont deja apparus : failles de securité, etc...
C'est le type de problème qu'on n'a pas du tout avec Java.
05/09/2002, 13h48
Epictète

Du coté des grands développements d'entreprises, ca va aujourd'hui très loin en sécurité coté java, avec mise en place d'architectures sécurisé à base de serveurs d'applications java sur des BUS CORBA plus implémentation SSL.

Plusieurs benchmarks on été fait par des grands comptes, et des grandes sociétés du secteur telecom, pas forcément publiés officiellement à cause des contrats imposés par les éditeurs, qui montrent qu'avec certains serveurs d'applications Java/CORBA on arrive à des architecture dites "incassable".

On en est très loin avec .NET qui débute...
05/09/2002, 13h54
VisualCBien

Citation:

Plusieurs benchmarks on été fait par des grands comptes, pas forcément publiés officiellement à cause des contrat imposés par les éditeurs,

Si pas publié, tu les lis ou en fait ? t'as une source ou deux, là ? Ou faut avoir une carte de club privé avec mot de passe au videur pour pouvoir lire l'article ? C'est juste pour me renseigner.
05/09/2002, 14h03
Epictète

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

:lol:

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...
05/09/2002, 14h42
mat.M

une véritable ineptie

La nouvelle plateforme de développement de Microsoft semble être une véritable ineptie car elle n'est compatible qu'avec...elle-même.
N'oubliez pas qu'il faille redistribuer un runtime .NET.
Bon j'avoue que je ne suis pas expert NET ni trop Java donc je suis sûr que des personnes contrediront mon avis et rectifieront le tir.
Mais NET est une ineptie car Microsoft a souhaité créer son propre Java...
Je m'explique :
Un point de détail qui n'est jamais abordé avec Java ou Net c'est l'affichage des contrôles sur un formulaire , crées dynamiquement , puisque programmes informatiques ou loigiciels distribués via Internet.
Vous voulez affichez un formulaire avec un bouton , avec Java ou NET : vous allez tapez quelque chose dans le genre :

Button mon_bouton;
mon_bouton=new Button();
mon_boton.Display();

Imaginez que vous ayez une fenêtre représentant le compte d'un client avec 50 boutons et 50 zones de saisies textes (J'ai bossé dans une SSII sur un projet avec 150 formulaires sous VB6 ! ).
Sous Java , la création dynamique se conçoit parfaitement puisque l'essence même de Java est d'être multi-plateforme donc lorsque vous chargez votre Applet sous Linux ou sous Mac OS , l'OS va se débrouiller pour afficher le ou les contrôles.
Avec C# et NET c'est la même chose : vous allez chargez une appli qui va afficher dynamiquement votre bouton ,alors que les contrôles sont DEJA contenus dans des dll , coeur même de Windows (comnctrl.dll , user.dll ,comdlg.dll...)

Comment cela se passait avant ?
C'est simple : avec Delphi , Borland C++ , Visual C++ voire même avec VB jusqu'au 6 , les contrôles sont crées lors de la conception , en design-time et compilés dans un fichier de ressource ( bien-sûr ils peuvent être crées dynamiquement ).

Donc je vous laisse imaginer concevoir un projet de gestion pour une banque avec C# chargeant des formulaires comprenant plus de 50 contrôles contenus chacun sur 100 formulaires .....

Maintenant ne désespérons pas :
Une personne a indiqué que Microsoft lançait sa plateforme avec 7 ans de retard...face à Java
Le problème de toute entité commerciale et particulièrement d'un éditeur de logiciel est qu'il doit mettre en vente une nouvelle version de ses titres tous les 2 ans environ :
Windows 95 en 95 , 98 en 98 , win2000 en 2000 etc...
Il en va de même pour Visual Basic : VB4 , VB5 et VB6. puis VB.NET
C'est pareil pour AutoDesk , ADOBE , Macromedia...

NE CRITIQUEZ pas .NET :
c'est cela qui va vous procurer un salaire !
Vu la conjoncture très défavorable ces temps-ci pour l'Informatique et les projets de progiciels , .NET va apporter une bouffée d'oxygène car , bien évidemment il va falloir migrer chez de nombreux clients finaux leur appli développée en VB4/5/6 vers VB.NET ou C#.
Je vous le dis tout de suite , je suis persuadé que cela n'apportera strictement rien de plus si ce n'est faire marcher le commerce et comme à l'accoutumée facturer les prestations.
Merci qui ??? La firme de Redmond
05/09/2002, 15h11
Nightfall

Citation:

Envoyé par Epictète

D'autant plus que .NET est tellement basé sur l'API Windows (cf de nombreuses discussions sur le site de Microsoft) que la portabilité me paraît totalement impossible, dans 10 ans ce sera toujours un projet...

Et Mono (http://www.go-mono.com), t'en penses quoi ?

Voir 40 message(s) de cette discussion en une page