C# versus Java [Débat]

[laffreuxthomas]

Meme avec .NET, on programme en Visual
Basic ou c# (ce dernier étant plus une politique commerciale qu'une aide au développeur).

D'après moi, la plate-forme .Net hérite de Java et Delphi.

Donc non, C# n'est pas un langage commercial. Il est destinés au programmeurs Objet, alors que VB.Net est plus utilisé par des développeurs procéduraux (même si les 2 langages sont équivalents). C'est un très bon langage qui corrige plusieurs défauts de Java :

* Impossible de récupérer plusieurs valeurs en sortie d'une méthode en Java (ie passage par référence de type de base)
* Nommage : les noms des accesseurs sont standardisés, et vérifiés par le compilateur (ce sont les "propriétés")
* Lors de l'implémentation de plusieurs interfaces, Java ne gère pas le cas de deux méthodes qui ont la même signature (2 méthodes homonymes peuvent signifier des choses différentes)
* En C#, on utilise des pointeurs de fonctions pour les évênements. C'est contestable, mais ça évite une instanciation supplémentaire qui a lieu pour les classes anonymes, avec souvent une unique méthode dedans...

Voili voilo. Je ne donne pas les inconvénients de la plate-forme .Net car ils sont déjà cités. Mais je n'ai pas rencontré d'inconvénients majeurs sur le langage C# proprement dit.

Thomas

[grishka]

Je m'apercoit que le débat aurait du être plutot entre c# et java : en gros
pourquoi avoir proposer c# si on a déjà java?
1-c# apporte réellement de nouvelles fonctionnalités. Donc Sun a oublié des choses dans java qui étaient réellement indispensables (sinon pourquoi?) J'attends des réponses car après tout c# a tout à fait le droit d'être meilleur que java (et la concurrence est bénéfique)
2-pour récupérer les programmeurs java
3-Ou les deux.

* Impossible de récupérer plusieurs valeurs en sortie d'une méthode en Java (ie passage par référence de type de base)
peux-tu préciser et donner un exemple stp?

* Nommage : les noms des accesseurs sont standardisés, et vérifiés par le compilateur (ce sont les "propriétés")

En java quel est la différence entre attribut et propriété d'une classe? c'est du vocabulaire propre aux JavaBeans. Un attribut est une propriété si il propose un moyen d'accés par get/set. En c# cela veut donc dire que tout les attributs sont des propriétés? ou est passée l'encapsulation alors?

* Lors de l'implémentation de plusieurs interfaces, Java ne gère pas le cas de deux méthodes qui ont la même signature (2 méthodes homonymes peuvent signifier des choses différentes)

Je ne vois pas vraiment l'intérêt et en plus cela induirait des incohérences de modélisation. En effet une interface peut modéliser le comportement d'un type d'obet. Donc si il existe une interface Fichier avec la méthode close() et une interface Fenetre avec aussi la méthode close(), est-il sensé de créer une classe qui implémente Fenetre et Fichier? Un objet qui se comporte comme une Fenetre et un Fichier, ca n'aide pas vraiment à bien programmer objet. Il existe peut être un problème moins naif que celui que je donne(dans ce cas exposez-le). En tout cas en programmation objet, la réutilisation passe aussi par la délégation et pas seulement par l'héritage

* En C#, on utilise des pointeurs de fonctions pour les évênements. C'est contestable, mais ça évite une instanciation supplémentaire qui a lieu pour les classes anonymes, avec souvent une unique méthode dedans...

d'accord à priori

d'autres différences à exposer?

[laffreuxthomas]

bah non, ton intervention était très bonne et ce débat est intéressant. :o) Ct juste pour élargir un peu le sujet.

en gros
pourquoi avoir proposer c# si on a déjà java?
1-c# apporte réellement de nouvelles fonctionnalités. Donc Sun a oublié des choses dans java qui étaient réellement indispensables (sinon pourquoi?) J'attends des réponses car après tout c# a tout à fait le droit d'être meilleur que java (et la concurrence est bénéfique)
2-pour récupérer les programmeurs java
3-Ou les deux.

.Net est un projet que Microsoft a commencé quand il s'est fait virer par Sun de Java (on sait pourquoi). C'est donc une réponse à Sun. Il n'est pas franchement innovant, mais il est aussi bien. Moins mature mais avec quelques améliorations, dans les grandes lignes. Le but est uniquement d'arrêter de perdre des parts de marché. Comme tu le soulignes, c'est une bonne chose que la concurrence.

plusieurs valeurs en sortie

Code :

1
2
3
4
5
6
7
8
  float res; int ech;
  calcule(out res, out ech, 2, 3);
// ...
  private void calcule(out float resultat, out int echelle, int val1, int val2)
  {
    echelle = 10;
    resultat = (float) val1 * val2 / echelle;
  }

Nommage et accesseurs
En Java :

Code :

1
2
3
    System.out.println(monObjet.getNumero());
  // ...
  public int getNumero() { return numero; }

En C# :

Code :

1
2
3
    Console.WriteLine(monObjet.Numero);
  // ...
  public int Numero { get { return numero; } }

C'est la même chose sauf que en C# le compilateur peut vérifier la syntaxe. Ca ne s'appelle pas un accesseur mais une propriété, en C#.

l'implémentation de plusieurs interfaces
Ton exemple est bon. Si tu en veut un plus cohérent, bah imagine que tu crées les interfaces de plusieurs évênements qui ont chacun une action par défaut (une méthode defaultAction(...), par exmple . Enfin c'est vrai que ça ne m'est pas encore arrivé. Mais c'est concevable.

Thomas

[grishka]

En java, tout est passé par valeur. La seule solution en java pour ton exemple si on veut faire exactement comme en c# :

Code :

1
2
3
4
5
6
7
8
  float[] res = new float[1]; int[] ech = new int[1]; 
  calcule(out res, out ech, 2, 3); 
// ... 
  private void calcule(float[] resultat, int[] echelle, int val1, int val2) 
  { 
    echelle[0] = 10; 
    resultat[0] = (float) val1 * val2 / echelle; 
  }

ce qui est moins bien car qui m'empeche de faire echelle[1] = 10?

les classes Float et Integer ne résolvent rien si je me trompe pas car ce sont des value-object, ie leur valeur est définie à l'instanciation. Et comme on peut pas faire echelle = new Integer(10)....

l'implémentation de plusieurs interfaces proposant la même méthode
oui à mon avis ca ne doit pas arriver tout les jours alors peut être que ca n'est pas vraiment utile surtout si ca permet des trucs délirants.

[grishka]

pour en revenir aux pbl des interface évoqué plus haut :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
public interface VehiculeRoulant {
 public avancer();
}
...
public interface Bateau {
 public avancer();
}
...
public class Hovercraft implements VehiculeRoulant, Bateau {
 public avancer() {
 }
}
...............
Hovercraft h = new Hovercraft();
VehiculeRoulant v = h;
Bateau b = h;

->en c#, si je veux, l'exécution de v.avancer() peut être différente de h.avancer().

Un hovercraft n'avance pas de la même facon sur terre et sur l'eau, c'est sur, mais cette distinction ne doit-elle pas être gérée de manière cachée dans l'implémentation de la classe Hovercraft ? L'objet est une boite noire pour l'utilisateur (principe d'abstraction par encapsulation).

Comment on ferait en java?
On peut s'attendre à ce qu'un objet VehiculeRoulant roule et ne flotte pas et inversement pour un objet Bateau. Il suffit d' une entité qui détecte l'environnement dans lequel évolue l'objet Hovercraft et fasse en sorte que les autres objets du modèle le voient en tant que VehiculeRoulant ou Bateau. Si j'ai une liste de VehiculeRoulant et une liste de Bateau, un hovercraft peut très bien passer de l'une à l'autre quand il change de milieu.

Bref, c# n'apporte pas ici quelquechose qui pourrait être résolu par analyse objet.

[laffreuxthomas]

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
public interface VehiculeRoulant { void PreparerAAvancer(); } 
public interface VehiculeVolant { void PreparerAAvancer(); } 

public class Ovni : VehiculeRoulant, VehiculeVolant { 
  void VehiculeRoulant.PreparerAAvancer() {
    RentrerElice();
    SortirRoues();
  }
  void VehiculeVolant.PreparerAAvancer() {
    RentrerRoues();
    SortirElice();
  }
  private void RentrerRoues() {	Console.WriteLine("RentrerRoues"); }
  private void RentrerElice() {	Console.WriteLine("RentrerElice"); }
  private void SortirRoues() {	Console.WriteLine("SortirRoues"); }
  private void SortirElice() {	Console.WriteLine("SortirElice"); }
} 

// ...

  private void PiloterVehiculeRoulant(VehiculeRoulant v) {
    v.PreparerAAvancer();
  }
  private void PiloterVehiculeVolant(VehiculeVolant v) {
    v.PreparerAAvancer();
  }

// ...

    Ovni ovni = new Ovni();
    PiloterVehiculeRoulant(ovni);
    Console.WriteLine("---");
    PiloterVehiculeVolant(ovni);

et voilà ! Et il y a même plus fort : on peut aussi décider, quand on écrit une méthode, si elle surcharge ou non celle de la classe mère. Ca permet d'éviter les fautes de frappes (en Java, une petite faute de frappe et c'est la méthode de la classe mère qui est appelée !). Et ça permet d'éviter les effets de bords si l'on modifie à postériori la classe mère sans connaître toutes les classes filles.

Mais je suis d'accord, c'est rare d'avoir des conflits de noms.

[laffreuxthomas]

Comment on ferait en java?
On peut s'attendre à ce qu'un objet VehiculeRoulant roule et ne flotte pas et inversement pour un objet Bateau. Il suffit d' une entité qui détecte l'environnement dans lequel

Oui, c'est une façon de faire. Mais la solution dans mon post précédant n'est pas moins objet. Et C# permet de faire les deux.

La fonctionalité de versions de méthodes est plutôt sympa. :o)

a+

[laffreuxthomas]

Autre différence : l'instanciation sur la pile
C# ré-utilise le mot-clef "struct" avec un nouveau sens : une structure est une classe dont toutes les instanciations seront faites sur la pile. Ca signifie que :
* le passage d'une instance de structure en paramètre se fait par valeur.
* pas d'allocation dynamique
* interdiction d'affecter 'null' à une variable de type struct

Très pratique pour les petites classes simples. Exemple : Color, Point sont des structures.

Les types built-in
... et par la magie du compilateur, un type 'int' est vu comme une structure. On n'a donc plus la dualité int / Integer , float / Float, etc..
Exemple :

Code :

1
2
3
4
      int nb = 2;
      ArrayList lst = new ArrayList();
      lst.Add(nb);
      Console.WriteLine(lst[0] + " " + nb.ToString());

En réalité la distinction entre l'entier physique et sa classe est tout de même gérée par le compilateur. Donc ce code n'est pas plus rapide à l'exécution que l'équivalent en Java. Mais il est vraiment plus simple à écrire !

Synthèse des améliorations de C# par rapport à Java
Le gros travail de Microsoft a été de réduire au maximum le nombre d'allocations mémoire sur le tas. Les paramètres en sortie, les pointeurs de fonctions pour évênements, les structures avec allocation sur la pile, servent à se servir de la pile au maximum. Ce qui donne un avantage intrinsèque à dot-Net en matière de rapidité d'exécution.

La gestion des versions de méthodes lors de l'héritage permet plutôt de gérer au mieux les problèmes de fusions de bibliothèques.

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 :

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

Au fait tout ce que je dis est valable pour C#, mais évidemment aussi pour tous les autres langages de dot-Net.

Thomas

[2000]

il me semble que s'il y a des details techniques (je suis plutot épaté par vos commentaires) la difference reside surtout au niveau economique et politique. par ailleurs, heureusement que C# comporte des ameliorations comparé à Java sinon ou serait son avantage ? Malgré tout je ne le vois que comme une tentative maladroite de MS d'endiguer l'engouement pour java.

On peut developper de grandes applications en java avec un environnement completement gratuit et de fait à moindre couts. Que ce soit au niveau des IDE (Eclipse), des serveurs Web (Tomcat) ou des serveurs d'applications (JBoss). Et puis il y a la philosophie "write once, run everywhere". Enfin, entre Windows, Office et I.E nous sommes suffisament pieds et poings liés à Microsoft pour l'être encore avec le développement.

Dans notre equipe nous avons migré de l'environnement ASP/VB pour java en diminuant nos frais de developpement ce n'est certainement pas pour passer maintenant a la plateforme .Net. Et je peux vous dire que ce genre d'arguments importent bien plus à mon project manager que toutes les ameliorations techniques apportées par C#.

[neo.51]

Envoyé par 2000

On peut developper de grandes applications en java avec un environnement completement gratuit et de fait à moindre couts.

Csharpdevelopp est un IDE C# entièrement gratuit, et pour ce qui est du choix de la plateforme, le projet go-mono avance à pas de géant : on a déjà tout ce qui est asp.net qui marche avec apache. Je pense que d'ici 1 ans on pourra développer des solution .NET sous linux de manière fiable.

[Clement Cunin]

Ce n'est pas parce que ca marche sous apache que c'est portable comme java...
Le C aussi est portable, en principe.... Mais dans la pratique ce n'est pas le cas. Java n'a plus rien a démontrer dans ce dommaine alors que dotNet n'en est qu'a ces débuts...

Comment dotNet et le projetgo-mono compte faire pour proposer une interface graphique portable ?
-> Une interface graphique entierement écrite en dotNet, entierement portable... et donc aussi lente que Swing ?
-> Une interface graphique basé sur une librairi graphique portable... comme SWT (avec les problème que l'on connait de gestion mémoire) ?
-> Le portage de l'Api windows sous linux ?
Ou alors le projet go-mono ne vise qu'a porter la plateforme sans de couche graphique (chose dont on a pas besoin pour de l'asp a priori ) ?

Et une fois que ca marchera sous linux, il reste plus qu'a le porter vers MacOs, Solaris, etc ...

[Nightfall]

Les winforms de go-mono sont basées sur gtk il me semble.

[neo.51]

Pour ce qui est de la portabilité de .NET sur linux, je ne dis pas que quand le framework.net sera porté sur linux ça sera du java, je dis que quand .NET sera porté sur linux, l'argument de la portabilitée en faveur de java ne sera plus valable. Par conséquent ça ne sert à rien de débattre en posant des arguments qui seront obsolètes dans moins d'un ans !

Pour ce qui est du portage de l'interface graphique, c'est en effet le problème majeur auquel se heurte le projet mono. Pour l'instant le portage de l'interface graphique se ferait avec GTK#...

Je pense que si DrQ passe dans le coin il pourra surement nous en dire plus.

Il n'empèche qu'avancer systèmatiquement le fait que java est moins couteux que .NET et que c'est portable sont des argument qui ne sont pas valable !!!

1)Acheter 3 licences windows et 3 licences VS.NET pour un projet qui se chiffre en milliers d'euros, je ne pense pas que l'on puisse parler d'un cout qui pénalise un projet.
2).NET sera portable dans moins d'un ans au moins sur linux
3)Il existe des outils entièrement gratuits pour développer en asp.
net, VB.NET ou C#


Alors si on fait un débat C# VS JAVA, parlons plutot de rapidité de développement, des possibilités qu'offre un langage et pas l'autre, du déploiement, de la maintenance, enfin bref les vrais argument qui joue en faveur de chacun de ces deux langages !

[Geronimo]

Deux liens intéressants en rapport avec le sujet :

- Qu'est-ce que C# :
http://msdn.microsoft.com/vstudio/te...sharpintro.asp
- Comparatif C#/Java/C++ : http://genamics.com/developer/csharp_comparative.htm

[okeefe]

Envoyé par neo.51

Pour ce qui est de la portabilité de .NET sur linux, je ne dis pas que quand le framework.net sera porté sur linux ça sera du java, je dis que quand .NET sera porté sur linux, l'argument de la portabilitée en faveur de java ne sera plus valable. Par conséquent ça ne sert à rien de débattre en posant des arguments qui seront obsolètes dans moins d'un ans !

Pour ce qui est du portage de l'interface graphique, c'est en effet le problème majeur auquel se heurte le projet mono. Pour l'instant le portage de l'interface graphique se ferait avec GTK#...

Je pense que si DrQ passe dans le coin il pourra surement nous en dire plus.

Il n'empèche qu'avancer systèmatiquement le fait que java est moins couteux que .NET et que c'est portable sont des argument qui ne sont pas valable !!!

1)Acheter 3 licences windows et 3 licences VS.NET pour un projet qui se chiffre en milliers d'euros, je ne pense pas que l'on puisse parler d'un cout qui pénalise un projet.
2).NET sera portable dans moins d'un ans au moins sur linux
3)Il existe des outils entièrement gratuits pour développer en asp.
net, VB.NET ou C#


Alors si on fait un débat C# VS JAVA, parlons plutot de rapidité de développement, des possibilités qu'offre un langage et pas l'autre, du déploiement, de la maintenance, enfin bref les vrais argument qui joue en faveur de chacun de ces deux langages !

même si mono est là, je vois pas pourquoi j'irais foutre du ms dans un système linux... on choisie linux par choix, c'est certainement pas pour apporter les bug ms avec nous

[Clement Cunin]

Envoyé par okeefe

même si mono est là, je vois pas pourquoi j'irais foutre du ms dans un système linux... on choisie linux par choix, c'est certainement pas pour apporter les bug ms avec nous

Attention a ne pas partir sur un troll à 2 euros ...

Le fait est que le code de l'api de dotNet n'est pas ouvert, ce qui est difficilement acceptable par un linuxien

Alors si on fait un débat C# VS JAVA, parlons plutot de rapidité de développement, des possibilités qu'offre un langage et pas l'autre, du déploiement, de la maintenance, enfin bref les vrais argument qui joue en faveur de chacun de ces deux langages !

Pour la rapidité de developpement, c'est pas les langages, mais les IDEs qu'il faut comparer.

Les possibilités qu'offre les langages sont equivalente, m$ a fait une copi quasi conforme...

La seule vrai difference, c'est la portabilité perdu au profit d'une meilleur integration a windows...

[Geronimo]

Clément, tu dis qu'il faudrait comparer la différence des IDE, mais là encore, cela risque de dépendre de chaque IDE...
Sur le plan vitesse à l'exécution, sais-tu si avec C# on garde le (petit) avantage de la vitesse du C/C++ ? (merci de ne pas troller sur Java + ou - rapide que C++, un débât entier y est consacré)

[Epictète]

Envoyé par Geronimo

Sur le plan vitesse à l'exécution, sais-tu si avec C# on garde le (petit) avantage de la vitesse du C/C++ ?

Cette question est bien connue, mais elle est mal posée, la question est qu'en est il de la rapidité d'exécution du code managé (.NET, n'importe quel langage, y compris C# ou C++) versus le code non managé (compilateur natif, C, C++ ou Delphi, ...).

La réponse est : Ca dépend.....

Ca dépend de ce que fait le code, de la taille du code, de la ram dispo, de la machine, et de plein d'autre choses.

Parfois le code non managé sera plus rapide, et parfois c'est l'inverse...

Mais de dire que l'un ou l'autre est plus rapide est donc faux, parce que cela dépend de la situation.

Cependant il est évident que à terme l'avenir est au code managé, Java ou .NET au choix, pour pleins de raisons...

[Clement Cunin]

Quand je vois tous les problèmes qu'on a avec les interfaces graphique en Java... alors que le langage est prevus a la base pour etre portable...

Réussir a porter les interfaces graphiques 100% windows vers une autre bibliotheque corresponds a mon avis a du suicide... AWT, Swing et SWT de java apporte chaqu'une autant de problème que de solution

- AWT utilise les librairie native de chaque OS, donc les fonctions se reduissent au plus petit denominateur commum... c'est a dire, pas grand chose de fonctionnel. Le look est plate forme dependant.
- Swing 100% java, est plus lente que des librairies natives. Le look est independant de l'OS.
- SWT le look est a moitier dependant de l'OS, mais on pert le garbage collector -> retoure des fuites de memoire -> la me-merde quoi !

Alors dire qu'on va faire tout ca avec gtk dans mono ... Lol !

Pour moi, dotNet sera portable quand 90% des application dotNet fonctionnerons aussi bien sur windows que sur Linux, sans modification du code...

[2000]

dire que l'argument de la portabilité n'est pas valable parce que dans un an si tout se passe bien C# sera portable c'est un peu faire preuve d'optimisme orienté à mon sens. Avancerais-tu cela aujourd'hui pour un projet à entamer comme argument à ton manager pour l'infléchir en direction de C# ? moi non.

d'accord pour dire que dévolepper des IHM avec Java c'est pas la panacée. Mais aujourd'hui la force de java est plutôt au niveau du serveur et de l'architecture J2EE et aussi du fait de son universalité : de l'IHM (un peu lourde d'accord) au serveur d'application à la generation de pages dynamiques, la gestion des transactions de la sécurité et de l'ensemble des activité de l'entreprise il n'y a qu'un language : Java.

Et puis d'une manière bassement pragmatique : la majorité des développements d'applications dans l'industrie sont en Java, la majorité des postes à pourvoir dans le développement le sont autour des technologies Java / J2EE (un rapport de 1 à 5 entre C# et Java sur jobserve.com le plus gros site d'emploi anglo-saxon) et maintenant que la plupart des entreprises ont migré vers cette technologie il me semble qu'il va etre délicat de les faire migrer de nouveau vers C#.

J'imagine plutot qu'il va y avoir une sorte de paix armée entre J2EE et .Net grâce aux WebServices.