Discussion :

[Bluedeep]

XAML c'est la traduction en balise des classes graphique de dotnet, je ne le vois pas trop prendre la place de IE , surtout que , contrairement à XUL, il n'est pas spécifiquement lié au navigateur

Attention : XAML n'est pas orienté uniquement IHM (A vrai dire, je ne connais pas grand chose aux IHM en général ) : c'est aussi le langage déclaratif pour le WFF. Je ne l'utilise d'ailleurs pour l'instant que dans cet usage.

[Bluedeep]

Dans une certaine mesure, oui. Mettons que c'est vrai pour VC#, VB, VC++, VJ# pour les produits Microsoft, ainsi que pour Delphi et eventuellement les tentatives de Cobol .Net, permettant de "recycler" des developpeurs Cobol pour faire du .Net.

Il n'y pas que Cobol. Il existe aussi par exemple un Fortran pour .Net; le but n'est pas tant de recycler les programmeurs dans ce cas, que de recycler des programmes (de modélisation par exemple) trés complexes à développer et surtout à tester, rendant leur redéveloppment totalement illusoire.
D'autant que ces programmes sont souvent écrits par des gens dont l'IT n'est pas la profession.
Par eemple, j'ai eu récemment sous la main un programme modélisant une dynamique de population de plancton à méso-echelle : 50 000 lignes de code d'une seule traite, un vrai chaos, mais qui marche (bien) : je ne voudrais pas imaginer son portage.

[sambarbas]

Raaaah ces inconditionnels de java ! Que des préjugés et des avis critiques !

Pratiquant les 2 depuis leurs débuts, je vote .net !

Compétition positive ! Eh oui Sun s'efforce de rattraper son retard. Sur les dernières versions les annotations, les enum, les generics, ... Et Tomcat (je déborde) qui en v6 utilise les mêmes méthodes .net (annotations) pour définir un service web. Ms aussi avec l'ajout des nullabletypes, manque grave avant la v2 !

Ya encore du boulot !

En java je réclame :
une strucutre dataset ;
surcharge d'opérateur ;
des classes partiels (intéressant lorsqu'il s'agit d'étendre une classe auto-générée sans risque de verrouiller le modèle par un héritage) ;
un switch avec d'autres types ;
Le virtual (fondamental !), Violent de modifier le comportement d'une méthode d'une classe parente sans que celle-ci l'y autorise ! Ah mais ça va Sun l'implémente en 1.5 (ou 1.6)
Les alias, le using, l'arobase pour les caractères d'échappement...

En c# j'exige :
Types exceptions potentielles dans la signature des méthodes
et qu'ils virent le goto !!! ^^

Sur l'environnement, .net est loin devant dsl...
vs2005 (5 instances et ca tourne pépère ! comparé au gargantuesque eclipse)
Débogage inter instance, du bonheur.
Le typage de dataset, le typage des ressources et le typage des paramètres d'application
La gestion des cultures, avec prise en compte qu'un changement de culture c'est des labels, mais également des tailles et des positions.
Extensions du concepteur (smarttags...).
Le must en dev html/js/css... avec un débogage javascript parfait (espions, points d'arrêts, curseurs...).

Documentation .net = xml (petite feuille xslt et hop ! ^^)
Javadoc = html (bof pour de "l'open" )

.....

Une communauté énorme autour de c#, des portages plus aboutis (nant, cruise control, nhibernate...)

.........

Boite noire le framework .net ? go télécharger reflector ! ^^ Par contre c'est sur on pourra pas modifier grand chose :p

................

Plus sérieusement, j'ai tout une pile d'arguments pour .net, mais dans la réalité c'est plus compliqué, les entreprises actuelles ont un legacy java conséquent, et plutôt que d'entretenir un débat stérile (gagné d'avance par dotnet), il vaut mieux chercher des moyens d'améliorer l'interopérabilité entre les 2.

[kedare]

Personellement ... la seul chose qu'il manque a .NET , c'est un portabilité complete , certe il y a mono , mais pour le desktop c'est pas terrible ... il faudrais un SWT-like , et ca serais parfait

[adiGuba]

il faudrais un SWT-like , et ca serais parfait

Il existe bien GTK#...

a++

[sinok]

Ainsi que QT# (qui un poil plus orienté objet de GTK#, QT étant écris à la base en C++) ou encore wx.NET.

Donc les toolkits cross platform ne manquent pas pour .NET

[kedare]

Il existe bien GTK#...

a++

oué enfin bon ... j'appel pas ca vraiment portable
quand tu vois la tronche du truc sur MacOsX :/
le QT sera pas mal par contre

[Aurazed]

Plus sérieusement, j'ai tout une pile d'arguments pour .net, mais dans la réalité c'est plus compliqué, les entreprises actuelles ont un legacy java conséquent, et plutôt que d'entretenir un débat stérile (gagné d'avance par dotnet), il vaut mieux chercher des moyens d'améliorer l'interopérabilité entre les 2.

Bravo, je ne vois pas quoi dire de plus! Je partage completement ta vision du sujet!

[Eric80]

Je viens de parcourir le topic en diagonale. Des arguments interessants des 2 côtes.
J ai appris le java en école d ing, et développe en C# au boulot depuis 2/3 ans, d abord en .NET 1.1 puis en .NET2.0
Le C# 2 (.NET 2.0) devient vraiment interessant (il manquait bcp de chose au .NET 1.1, autant au niveau du langage que des classes du Framework).

Je me permet une citation de la 1ere page (qui date un peu).

Tout petit défaut de c#
Sinon j'ai trouvé un petit défaut à C# : la visibilité d'une propriété (ie accesseur) est forcément la même pour un get et un set. Alors qu'on a souvent besoin d'un set protected ou internal (ie package) avec un get public. Dans ce cas on est donc obligé de revenir à l'ancienne manière pour un des deux :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
  internal void SetNom(string nom) { this.nom = nom; }
  public string Nom { get { return nom; } }

Thomas

Typiquement un truc qui ne fonctionnait pas en C# 1, mais bien en C#2

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
public string Nom
{
	get { return nom;}
	internal set { nom = value;}
}

[khayyam]

bonjour a tous
voila moi j'suis de ceux qui font fasse a ce cruel dilem qu'est java ou C# et franchement vous m'aidez pas beaucoup, a chaque fois que je lis un post je suis plus indecis,
je suis etudiant en informatique, j'maitrise deja le C et un peu de delphi, et je veux apprendre mais j'hesite entre java et C#,

si j'devais faire un resumé j'dirait :

un bon point pour le C# et .Net c'est l'affiliation microsoft et j'pense que d'ici quelque années (le temps d'avoir le diplome) C# sera le language de programmation par defaut dans toutes les entreprise, par contre sa portabilitée(ou plutot le manque de portabilitée) est un desavantage majeur
vous m'dirait il y'a mono mais franchement je sais pas ce que ça vaut vraiment et si ça va continuer d'etre developper pour les futur version de C #

Sinon pour java un bon point est sa portabilitée et sa large diffusion, et puis les mauvais point y'a peut etre l'aspect graphique qui est un peu negliger, et puis pleins d'autres trucs techniques que j'ai pas compris.

pour ma part j'veux developper des jeux pour telephone portable, je sais que java le fait tres bien, mais j'voudrai savoir si on peux developper avec du C# sur n'importe qu'elle plate-forme mobile notamment avec mono, si c'est affirmative je choisis C# de suite

Merci

[khayyam]

bonjour a tous
voila moi j'suis de ceux qui font fasse a ce cruel dilem qu'est java ou C# et franchement vous m'aidez pas beaucoup, a chaque fois que je lis un post je suis plus indecis,
je suis etudiant en informatique, j'maitrise deja le C et un peu de delphi, et je veux apprendre mais j'hesite entre java et C#,

si j'devais faire un resumé j'dirait :

un bon point pour le C# et .Net c'est l'affiliation microsoft et j'pense que d'ici quelque années (le temps d'avoir le diplome) C# sera le language de programmation par defaut dans toutes les entreprise, par contre sa portabilitée(ou plutot le manque de portabilitée) est un desavantage majeur
vous m'dirait il y'a mono mais franchement je sais pas ce que ça vaut vraiment et si ça va continuer d'etre developper pour les futur version de C #

Sinon pour java un bon point est sa portabilitée et sa large diffusion, et puis les mauvais point y'a peut etre l'aspect graphique qui est un peu negliger, et puis pleins d'autres trucs techniques que j'ai pas compris.

pour ma part j'veux developper des jeux pour telephone portable, je sais que java le fait tres bien, mais j'voudrai savoir si on peux developper avec du C# sur n'importe qu'elle plate-forme mobile notamment avec mono, si c'est affirmative je choisis C# de suite

Merci

[super_navide]

Ma réponse apprend les deux si tu peut.

Moi j'ai une préférence pour Java qui un plus libre que C#
et qui possède plus de framework et d'outils


Moi je trouve ca nulle qu'il y est deux langage qui sont font concurrence moi je voudrais un unique plateforme java# qui sois un mélange des deux avec plusieur langage disponnible

[Médinoc]

Dans ce cas, ce ne serait pas sur le runtime Java, en tout cas: Il ne supporte pas la moitié de ce que peut faire le CLR (paramètres référence, types génériques reconnus par le runtime, types valeur complexes...).

[duncan55]

Pour compléter ce qui précède, ce qui me manque vraiment beaucoup en .NET c'est la visibilité package.

Si on veut concevoir des espaces de noms structuré avec des fabriques (ou autre design pattern) on ne peut pas empecher la visibilité d'une classe au reste du code. C'est tout visible ou rien.

J'espère vraiment qu'ils vont l'ajouter un jour ou l'autre car pour la conception c'est très handicapant je trouve.

(Avant que quelqu'un ne le fasse : la visibilité internal ne permet pas du tout d'émuler cette visibilité d'espace de noms)

Ensuite en deuxième, je dirais comme plus haut : la déclaration des exceptions lancées. Je trouve hallucinant d'appeler une fonction et de ne pas savoir à 100% quelles exceptions elle retourne


Je n'ai pas choisi entre Java et .Net et contrairement à ce qui a été dit je trouve justement qu'avoir 2 langages est une vrai force. Java s'est considérablement amélioré depuis l'arrivée de .NET et la réciproque fut ensuite vrai. La concurrence c'est toujours mieux que le monopole

[sambarbas]

Pour compléter ce qui précède, ce qui me manque vraiment beaucoup en .NET c'est la visibilité package.

Si on veut concevoir des espaces de noms structuré avec des fabriques (ou autre design pattern) on ne peut pas empecher la visibilité d'une classe au reste du code. C'est tout visible ou rien.

J'espère vraiment qu'ils vont l'ajouter un jour ou l'autre car pour la conception c'est très handicapant je trouve.

(Avant que quelqu'un ne le fasse : la visibilité internal ne permet pas du tout d'émuler cette visibilité d'espace de noms)

Ensuite en deuxième, je dirais comme plus haut : la déclaration des exceptions lancées. Je trouve hallucinant d'appeler une fonction et de ne pas savoir à 100% quelles exceptions elle retourne


Je n'ai pas choisi entre Java et .Net et contrairement à ce qui a été dit je trouve justement qu'avoir 2 langages est une vrai force. Java s'est considérablement amélioré depuis l'arrivée de .NET et la réciproque fut ensuite vrai. La concurrence c'est toujours mieux que le monopole

+1 !

Par contre en ce qui concerne la définition des exceptions dans la signature d'une méthode, je ne suis plus très sur de l'intérêt, je pense même que cela peut être source de problèmes d'un point de vue compatibilité ascendante.

Imaginons je modifie une méthode qui dans une version n-1 pouvait jeter une IOException. Dans une version n, cette méthode ne rejette plus cette exception, donc plus besoin de la définir dans la signature et par conséquent les dépendances et autres appels à cette méthode ne sont plus compatibles... Peut être que des options du compilateur ou autres permettent de palier à ce pb, je n'en sais rien mais si ce n'est pas le cas c'est un gros -1 pour java et un gros +1 pour .net.

[adiGuba]

Imaginons je modifie une méthode qui dans une version n-1 pouvait jeter une IOException. Dans une version n, cette méthode ne rejette plus cette exception, donc plus besoin de la définir dans la signature et par conséquent les dépendances et autres appels à cette méthode ne sont plus compatibles... Peut être que des options du compilateur ou autres permettent de palier à ce pb, je n'en sais rien mais si ce n'est pas le cas c'est un gros -1 pour java et un gros +1 pour .net.

Cela ne pose qu'un problème de compatibilité des sources :

• Si on supprime une exception alors le compilateur indiquera qu'elle est inutilement catché.
• Si on en rajoute une alors le compilateur indiquera qu'elle n'est pas catché

Par contre cela n'a aucun impact sur le code déjà compilé :

• Si on supprime une exception alors le code déjà compilé utiliser un bloc catch inutilement mais fonctionnera de la même manière.
• Si on rajoute une exception elle ne sera pas traité par le bytecode existant puisque le bloc catch n'est pas présent.

Perso je pense que les checked-exception sont un point fort de la gestion des exceptions de Java, même si malgré cela on retrouve beaucoup de traitement "à l'arrache" des exception.

A noter que Java autorise aussi des "unckecked-exception" : toutes les exceptions qui hérite de RuntimeException ne doivent pas être obligatoirement catché (même si elles sont déclaré par la méthode).

a++

[rberthou]

Java ou C#...

Personnellement le problème est "puis-je faire encore confiance a MS".

Je développe depuis plus de 15 ans et durant tout ce temps j'ai vu trop souvent l'offre MS changer radicalement de coté.

- les VBX (oui c est vieux je sais) sont passés abandonné a la sortie de Win32 car non compatible avec Win32 ( borland propose une solution acceptant ces composant sous Win32 )
- a la sortie de java MS le soutient et propose une solution très simple pour créer des activeX serveur . Puis abandon ...
- l'offre VB ... qui reste a VB 6 si on en veux pas réécrire une grande parti de son code
- ..

J'ai perdu ma confiance dans les outils de développement MS après ces nombreux changement de technologie m'obligeant a réécrire un partie de certain projet.

C'est pour cela que mon choix se porte sur Java.

[blbird]

Je conçois très bien que si on a été développeur VB, tout les changements apportés peuvent faire regretter le choix Microsoft. DotNet est cependant, je pense, une plateforme sûre sur le long terme, surtout avec C#.

De toute manière, les langages évoluent, naissent et meurent. Ce sont les concepts qui sont importants.

L'émulation entre ces 2 langages pérènnes que sont Java et C# est au final très bénéfique pour tout le monde.

Je lutte pour ne pas faire de commentaire sur le VB. Argh, je n'ai pas réussis.

[rberthou]

Je conçois très bien que si on a été développeur VB, ...

Comme dis précédemment en 15 ans j'ai touche a beaucoup de langages dont VB. Ce dernier m'avait beaucoup plus lors de sa sortie (presque autan que HyperCard) par contre je ne me considère pas du tout comme un développeur VB.

DotNet est cependant, je pense, une plateforme sûre sur le long terme, surtout avec C#.

Je suis d'accord avec cela mais maintenant j'ai un apriori négatif sur les Outils MS (de plus on peut difficilement s'investir en même temsp sur J2EE et Dot Net).

[sambarbas]

Bonjour

Mon choix est fait : Java.

Non sérieusement je n'ai pas testé C# (et j'en ai pas trop envie).


Bah les annotations c'est vraiment trop top terrible

Exemple pour hibernate : http://www.hibernate.org/247.html
Exemple pour EJB Entity : http://java.sun.com/javaee/5/docs/tu....html#wp996871

Bref que du bonheur

Maintenant si tu préfère tout te taper dans des fichiers XML ..........

tchuss

Entre parenthèse, C# a intégré le principe d'annotations bien avant java (1.5 il me semble). Idem pour les generics, les enumérations etc etc...

Voila tout l'intérêt d'avoir 2 solutions qui se tirent la bourre en terme d'évolutions techniques.