Discussion :

[adiGuba]

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

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

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)

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.

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

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

Java 6 ou SwingLabs si tu es préssé

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

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

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

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

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

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

[Luc Hermitte]

<disgression>

[...] 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.
</>

[adiGuba]

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

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

[Commodore]

les 2 sont biens et se ressemblent dans la façon de faire.
cependant, une petite préférence pour Java :p

[kedare]

C# : Java
1 : 0

en meme temp ton post est quand meme vachement orienté pro-C# ....

[duncan55]

Bonjour tout le monde,

Je developpe en C# et en Java. Les deux ont leurs points faibles et leurs avantages.

Toutefois, j'ai un problème avec C# concernant la visibilités des classes/méthodes/attributs.

Il n'existe pas de juste milieu entre public et private en C#.
Java a bien package (absence de modificateur) pour indiquer que l'élément n'est visible que dans le package. En C# il n'y a pas d'équivalent, internal indique que l'élément est visible dans l'assembly (autant dire le programme) mais il n'est pas possible de limiter la visibilité au sein de l'assembly a part le rendre privé (je passe volontairement l'héritage avec protected)

Je ne sais pas si d'autres développeurs C#/.NET ont le même problème mais je trouve que c'est une grosse lacune car cela limite grandement la conception et l'architecture d'une appli.

Je me retrouve avec tout plein de classes visibles partout alors qu'elles n'ont pas de raisons d'être en dehors de leur espace de nommage.

[h4cker]

Salut a tous.
J'ai plusieurs remarques sur ce qui a été dit.
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.
Ensuite, le cout. Pour avoir travaillé sur plusieurs tres gros projets à plus de 15 000 K€ en java, j'ai pu constater que finalement le J2EE ne revenais pas moins chere que le .NET. En effet, des que l'on veux implementer des solutions tel que des moteurs de regles ou d'autres chose encore, les editeur facture a prix d'or leur produit (bien plus que microsoft) .En comparaison, un Jrules et bien plus chere qu'un biztalk). De plus, le temps de devellopement est bien plus long avec du java qu'avec du .NET (Merci VS2005). De plus, on remunére les ressources un peu plus chere pour les experts Java que pour les .NET.
Neamoins, je dois avouer que mes remarques ne sont peut etre pas fondé pour des petits projets.

[Médinoc]

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

[adiGuba]

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

[KiLVaiDeN]

Salut,

J'ai voté pour Java.

Ayant pratiqué les deux langages, avec une plus longue expérience sur Java, j'ai toujours eu l'impression de faire du Java au final; C# ressemble beaucoup trop à Java, et de fait, il perd à mes yeux de la crédibilité, et me fait penser à une vaste supercherie de Microsoft pour reconquerir les utilisateurs Java dans leur monde.

C#, et la plateforme .NET en général, est encore une magouille pour attirer un max d'entreprise dans les filets; une fois le code pour .NET produit, impossible de faire autrement que de faire confiance au support microsoft, aux outils microsoft, aux plateformes microsoft, et même dans une certaine mesure aux bases de données microsoft.

Dans l'esprit donc, Sun a toujours eu démarche plus saine et positive que Microsoft, dans le sens ou Sun a voulu créer un produit performant et portable, pour toucher les utilisateurs grâce à la puissance du langage, et non à la puissance d'une "marque".

Après, les spécificités des langages, c'est un débat sans fin, trouver quel langage est mieux ou pas, c'est vraiment à mon avis un peu inutile, car au final, on peut faire tout ce qu'on souhaite avec les deux, moyennement plus ou moins d'effort ( et encore, sur ce point, je n'aime pas les outils de developpement Microsoft où on se sent trop "Guidé", il faut utiliser des wizards à gauche à droite, et ça a le don de m'enerver ! )

A+

[Woufeil]

Salut,

J'ai voté pour Java.

Ayant pratiqué les deux langages, avec une plus longue expérience sur Java, j'ai toujours eu l'impression de faire du Java au final; C# ressemble beaucoup trop à Java, et de fait, il perd à mes yeux de la crédibilité, et me fait penser à une vaste supercherie de Microsoft pour reconquerir les utilisateurs Java dans leur monde.

Et bien, en fait M$ ne s'en en jamais caché... Mais si l'on trouve que la copie est meilleure que l'original, pourquoi la bouder ?

C#, et la plateforme .NET en général, est encore une magouille pour attirer un max d'entreprise dans les filets; une fois le code pour .NET produit, impossible de faire autrement que de faire confiance au support microsoft, aux outils microsoft, aux plateformes microsoft, et même dans une certaine mesure aux bases de données microsoft.

Oui, c'est un peu vrai, mais ça ne dérange pas forcément.
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.

C'est pour ça que j'ai répondu que j'aime avoir l'alternative entre Java et C# (même si j'aurais pluôt dit .NET) : 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é.

[adiGuba]

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

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

[Woufeil]

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

Exact, mais à long terme le marché serait quand même perdu je suppose... Mais c'est vrai que je pense trop en tant que "développeur" (le mot est bien grand pour ce que je fais ) indépendant et non au sein d'une entreprise

[mat.M]

C#, et la plateforme .NET en général, est encore une magouille pour attirer un max d'entreprise dans les filets; une fois le code pour .NET produit, impossible de faire autrement que de faire confiance au support microsoft, aux outils microsoft, aux plateformes microsoft, et même dans une certaine mesure aux bases de données microsoft.

Je n'irai pas te contredire .
Tu ne dois pas être loin de la vérité
Par contre je trouve le mot "magouille" un peu déplacé

et encore, sur ce point, je n'aime pas les outils de developpement Microsoft où on se sent trop "Guidé", il faut utiliser des wizards à gauche à droite, et ça a le don de m'enerver ! )
A+

Ne t'inquiète pas tu n'est pas le seul et avec Windows Vista ça sera pire.
Quand tu vois que sous XP , un programme tourne en tache de fond pour savoir si...toutes les icones du bureau sont bien utilisées.
J'apprécie les outils M$ je ne suis pas un détracteur mais y'a des limites à la bétise

[mat.M]

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

Cela fait des lustres qu'on nous dit que le client lourd c'est fini et que demain ce sera du tout internet.
Alors dans cet optique l'éditeur de Redmond est en faillite alors étant donné que jusqu'à présent il tirait bénéfice de ses suites bureautiques ?
Open Office ? Excusez-moi je pouffe
Et c'est pas un client web mais également un client lourd aussi.
Le tableur sur Google ? On en reparlera d'ici quelques temps

[sinok]

Le tableur sur Google ? On en reparlera d'ici quelques temps

Par contre ThinkFree Office réalisé en java apporte tout de même un début de réponse à ce niveau là, même si bien on est loin d'office... c'est déja largement plus que le tableur google, avec enplus des possibilités de partage, les documents word et powerpoint passent plus ou moins bien.... Bon ensuite il est vrai que c'est du client riche (applet) et non du client léger et que ça n'atteind pas encore le niveau d'OOO, donc pas celui d'office...
Mais bon ça illustre bien un des derniers gros avantages de java, la portabilité, que ce soit au niveau plateforme ou outil utilisé (pour moi firefox mais ça aurait pu être n'importe quel browser sur lequel vient se greffer le plugin JVM).

[deneb]

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

AJAX, Web 2.0...Comme tu dis, à mi chemin, le cul entre deux chaises. Avec surtout les inconvénients des deux mondes !

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

Et oui...sans compter sur la lourdeur des composants embarqués...

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

Ahhhh ...dans mes bras

[MicaelFelix]

Moi j'ai voté pour "J'apprécie le fait d'avoir l'alternative Java ou C#" car au moins si on veut un logiciel qui tourne sur toutes les plateformes il faut choisir Java, mais si on pointe plutôt sur la qualité d'affichage de l'interface utilisateur, C# est plus orienté Windows... donc plus pratique si on veut faire des interfaces graphiques optimisées pour windows (mon cas).
Bref faut choisir faire en fonction des besoins!

KiLVaiDeN a écrit :
et encore, sur ce point, je n'aime pas les outils de developpement Microsoft où on se sent trop "Guidé", il faut utiliser des wizards à gauche à droite, et ça a le don de m'enerver ! )
A+

Ne t'inquiète pas tu n'est pas le seul et avec Windows Vista ça sera pire.
Quand tu vois que sous XP , un programme tourne en tache de fond pour savoir si...toutes les icones du bureau sont bien utilisées.
J'apprécie les outils M$ je ne suis pas un détracteur mais y'a des limites à la bétise

Il ne faut oublier non plus que ce genre de gadgets facilitent l'utilisation de Windows pour les débutants (qui consituent quand même une grande part de la clientèle de Windows), et qu'on peut facilement les désactiver!

[super_navide]

il vrais que c# apporte pas mal de truc en plus mais il n'est pas aussi portable que java ,mais c'est bien souvent du sucre syntaxique .


de plus java possède déja un quantité importante d'outil et de framework que c# ne possède pas .
de plus java évolu continuellement et comble c'est lacune (example avec les générique )
et bientot avec les closures .

[Erwy]

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)

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