C# versus Java [Débat]

Envoyé par scifire

Les generics en Java ce ne sont pas de "vrais" generics. Tout simplement c'est le compilateur qui fait les casts necesaires. Pendant l'execution du programme un ArrayList<String> est un ArrayList<Object>.

C'est vrai (en partie puisque à l'exécution le typage est perdu c'est ArrayList et non pas ArrayList<Object>, mais cela revient au même je le l'accorde). Et c'est justement le gros avantages des Generics sur les templates du C++ (je ne parle pas des Generics de C# que je ne connais pas) :

• Tu conserves une compatibilité ascendante et tu peux utiliser les versions non génériques des classes (utile pour la migration ou l'utilisation de vielles librairies).
• Tu peux les utiliser massivement dans ton code (et ainsi avoir du code sécurisé) sans que cela ne te génère de recopie de code : ton code est unique même à l'exécution (avec les templates du C++ tu as une copie du code par type utilisé en templates).

Par contre c'est vrai que tu conserves les coûts des cast (implicites).

Envoyé par scifire

De plus un ArrayList<int> n'existe pas donc il faut passe par un Integer et par le boxing/unboxing( on le paye).

Je suis d'accord avec toi sur ce point : le boxing/unboxing (conversion des types primaires en une instance de la classe associé, pour ceux qui l'ignorerait) n'est pas vraiment une bonne chose car elle cache des mécanismes qui peuvent s'avérer assez lourd...

Envoyé par scifire

Quant aux annotations est-ce qu'ils simplifient la vie de programmeur d'une maniere ? Pas du tout. C'est de maquillage ca.

Et pourtant les annotations sont et seront de plus en plus utilisé...

De plus Java 5.0 ne se limite pas seulement à cela, et l'API s'est bien enrichi (je pense notemment à l'API de concurrence : java.util.concurrent)

Envoyé par scifire

Java 6.0 ??? Il va pas proposer quoi ? http://java.sun.com/developer/techni...g_build39.html
Dans cette liste je ne vois rien d'interessant.Meme il y a certains qui me font rire par exemple

Tu te limites à un exemple sur une liste partiel qui a près d'un an pour indiquer que cela n'apportera rien...

Dans Java SE 6 tu trouveras entre autres :

• JDBC 4.0 (qui utilisera entre autres les Annotations).
• Une meilleure intégration au bureau (systemtray + association de fichier)
• Une API de scripting (interaction avec des langages de scripts).
• Une API de compilation dynamique de code Java
• Des améliorations Swing (JTabbedPane personnalisable, trie/filtrage des JTable, nouveau modèle de modalité, Drag And Drop amélioré, SwingWorker, nouveau LayoutManager...)
• Intégration de l'Annotation Processor Tools (traitement automatique des annotations à la compilation)
• Un meilleur support des LookAndFeel systèmes.
• etc.

Envoyé par scifire

JFileChoose - on ne peut pas supprimer des fichiers et la selection est un peu bugge.

Pour la suppression c'est vrai... mais je n'ai pas de problème particulier de bug...
Par contre le JFileChooser avec le LookAndFeel de Windows n'est pas terrible...

Envoyé par scifire

JTable - il n'y a pas de tri par default.

Java 6 ou SwingLabs si tu es préssé

Envoyé par scifire

Les composants supporte HTML 3.2

C'est vrai : en même temps l'objectif était juste de proposer un langage de présentation simple, pas de concevoir un navigateur
Toutefois il y a une demande sur ce point et j'ai vu une étude pour intégrer un moteur XHTML 1.1/CSS2... mais ce ne sera pas pour Java 6.0

Envoyé par scifire

Swing n'est pas complet. Il y a des composants de base qui MANQUENT.

Il y a un grand nombre de composant non-standard de disponible...

Envoyé par scifire

La performance. J'utilise Eclipse(SWT) et je suis content de la performance et tout. J'ai volu juste voir ce que Netbeans(Swing) propose. Il est tellement lent qu'il est pratiquement inutilisable(AMD Semprom 3.3 GHz, 1GHz RAM).

Swing a été grandement amélioré avec Java 5.0, et le sera encore pour le 6...

Envoyé par scifire

XML le traitement de fichiers XML en Java c'est la gelere. Heureusement il y a le JDOM.

Heu... j'avoue ne pas faire beaucoups de XML...

Envoyé par scifire

JavaEE 5.0 et SOA
Comme Sun s'oriente vers les entreprises, les developpeurs d'applications de bureau sont oublies. Ils devront se contenter avec Swing tel qu'il est car il va pas changer dans les annees qui suivent.

Swing n'est pas du tout abondonné, au contraire il revient en force avec les améliorations de Java 5.0 et 6. Sun a d'ailleurs présenté une joli démo pendant JavaOne : http://jroller.com/page/gfx/?anchor=...ery_cool_swing

Envoyé par scifire

Les features de C# 3.0 sont vraiment des features de langages qui simpifient le developpment d'applications.

Tu pourrais détailler : c'est intérressant

a++

<disgression>

Envoyé par adiGuba

[...] Et c'est justement le gros avantages des Generics sur les templates du C++ (je ne parle pas des Generics de C# que je ne connais pas) :
* Tu peux les utiliser massivement dans ton code (et ainsi avoir du code sécurisé) sans que cela ne te génère de recopie de code : ton code est unique même à l'exécution (avec les templates du C++ tu as une copie du code par type utilisé en templates).

Ce n'est pas nécessaire. C'est généralement le cas, mais des bons compilos peuvent être à même de reconnaitre un conteneur de pointeur p.ex. Pour les types à sémantique de valeur, il faut oublier. A la limite "unsigned int" et "int" sont factorisables (avec reinterpret_cast<> implicites aux fonctions d'interfaces), mais c'est à peu près tout. Jouer avec la méta-prog va compliquer la tâche également.

Il faut voir aussi que pour la recopie de code ... en fait, c'est aussi souvent comme s'il n'y avait pas d'appel de fonction, pour les plus courtes. Le code est inliné. Le [] ou le for_each se traduisent en le code classique où l'on aurait directement tapé les for() avec nos petites mains sur un tableau classique -- dans le cas std::vector<> qui présente beaucoup de petites fonctions.
</>

Envoyé par Luc Hermitte

<disgression>
Ce n'est pas nécessaire. C'est généralement le cas, mais des bons compilos peuvent être à même de reconnaitre un conteneur de pointeur p.ex. Pour les types à sémantique de valeur, il faut oublier. A la limite "unsigned int" et "int" sont factorisables (avec reinterpret_cast<> implicites aux fonctions d'interfaces), mais c'est à peu près tout. Jouer avec la méta-prog va compliquer la tâche également.

Ok! Mais je parle principalement de classes et non pas des types primaires.

Envoyé par Luc Hermitte

Il faut voir aussi que pour la recopie de code ... en fait, c'est aussi souvent comme s'il n'y avait pas d'appel de fonction, pour les plus courtes. Le code est inliné. Le [] ou le for_each se traduisent en le code classique où l'on aurait directement tapé les for() avec nos petites mains sur un tableau classique -- dans le cas std::vector<> qui présente beaucoup de petites fonctions.
</>

L'inlining est aussi présent en Java (dynamiquement lors de l'exécution). La recopie dont je parle concerne les méthodes/fonctions assez conséquentes pour ne pas être inliné...
Ce que je voulais dire c'est que si les Generics conserve les cast des types à l'exécution, ces derniers sont assez rares (lors de l'appel des méthodes get() seulement).

Ce que je voulais dire c'est que les Generics de Java ont une approche totalement différente des Templates du C++, mais que ce n'est pas pour autant qu'ils sont négligeables ou pas performant...

a++

duncan55 : Si tu as dans l'assembly des classes qui ne devraient pas être visibles partout dans celui-ci, peut-être ne l'as-tu pas assez décomposé...

Envoyé par h4cker

Tous d'abord, la portabilité du code...Pourquoi cela enflamme t'il autant les gens de savoir que leur code est portable. L'avenir est au client web et plus au client lourd. Donc la portabilité du code n'est que peu importante.

Je ne suis pas tout à fait d'accord : Avec AJAX on est passé du client Web "traditionnel" à un client Web "riche", qui correspond un peu à un mixte entre le client léger (pour l'absence ou quasi-absence de déploiement) et le client lourd (pour l'interface plus ergonomique et les possibilitées quasi-infini).

Mais les limites des navigateurs sont un frein assez conséquent (incompatibilitée des implémentations, support différent des technologies...)

Or le client "riche" ne se limite pas à AJAX, mais peut prendre d'autre forme tel qu'une application Java Web Start, Flash, XUL ou encore XAML, qui permettent de prendre le meilleurs des deux mondes : un déploiement simplifié puisque l'application est automatiquement téléchargée par le client, et une interface riche qui permet bien plus de chose qu'une "simple" page web.

Du coup la portabilité peut être importante !

a++

Envoyé par Woufeil

Je m'explique : si M$ fait un sale coup avec .NET (rendre tout plus ou moins payant, faire des outils pas extrêmement perfirmant, mettre des spywares dans les logiciels...) tout le monde repassera illico à Java.

Sauf que ce n'est pas aussi facile !
Une fois que tu as developpées toutes tes applications dans un langage tu restes plus ou moins lié à ce dernier, car c'est assez coûteux (en temps et en argent) de tout recommencer...

Le problème c'est que Microsoft est seul aux commandes de .NET, et qu'il pourrait ainsi fortement modifier son(ses) langage(s) et sa plateforme...

Ce n'est pas le cas avec Sun, où tout ce qui touche à Java est généralement soumis au Java Community Process auquel participe plusieurs entreprises (dont IBM, Oracle, Google et plusieurs société de téléphonie pour ce qui concerne Java ME). Du coup le processus d'évolution est plus long mais plus controlé (ceci n'est bien sûr qu'une opinion personnelle).

Envoyé par Woufeil

le fait d'avoir une telle concurence entre les deux langages empêche les faux pas d'un côté comme de l'autre, sous peine de perdre le marché.

+1 et ca tire tout le monde vers le haut :

• Chacun veut en faire au moins autant que le concurrent.
• Chacun cherche à se démarquer du concurrent via l'innovation.

a++

Envoyé par adiGuba

Mais les limites des navigateurs sont un frein assez conséquent (incompatibilitée des implémentations, support différent des technologies...)

C'est chiant, mais si on se limite au couple IE/FX on garde un ensemble de techno tres puissant , même si les différence syntaxique sont penible (il existe neanmoins des projets pour combler ce pb comme Sarissa, mais je n'ai jamais pu les utiliser et ne peut donner mon avis)

Envoyé par adiGuba

Or le client "riche" ne se limite pas à AJAX, mais peut prendre d'autre forme tel qu'une application Java Web Start, Flash, XUL ou encore XAML, qui permettent de prendre le meilleurs des deux mondes : un déploiement simplifié puisque l'application est automatiquement téléchargée par le client, et une interface riche qui permet bien plus de chose qu'une "simple" page web.

Je vais mettre un bémol.
Mon boulot ce sont les interfaces riches en HTML (javascript/ajax/xml and Co). J'ai naturellement orienté mes recherches vers XUL au bout d'un moment et , comme d'autres dans ma partie, j'ai laissé tombé.
Si pour un débutant dans cette partie, réalisé des choses simples avec XUL, est bien mieux au depart, des qu'on touche au complexe , et qu'on est obligé d'utiliser les RDF et XBL , adjoindre du HTML.... Cela devient bcp plus lourd et bcp plus complexe ,tres lourd àdéployer pour un gain en fonction trop faible. Pour ce que j'ai vu d'ailleurs XAML ne s'oriente pas non plus dans ce sens . 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