Discussion :

[adiGuba]

En java c'est radicalement différent c'est du pseudocode à réinterpréter

Le bytecode peut être compilé à la volé et bénéficier des mêmes avantages que le code natif (et même plus puisque toutes les spécificités de la machine hôte sont connu, et qu'il peut utiliser l'état de l'application pour optimiser encore plus le code).

faut vérifier s'il n'y pas d'exceptions

C++ aussi possède un système d'exception... je crois que je n'ai pas bien compris ce que tu voulais dire par là...

s'il n'ya pas d'erreur mémoire avec le Garbage Collector...

Pourrais-tu préciser ??? Le passage du GC peut être long dans certain cas, mais dans la plupart des cas il est plus performant qu'une gestion à la main de la mémoire...

http://citeseer.ist.psu.edu/rd/43437...optimizing.pdf

J'ai eu le temps d'y jeter un coup d'oeil... c'est très intéressant mais cela ne parle pas de compilation JIT mais d'interprétation de bytecode ! Or il y a quand même un fossé énorme entre les deux en terme de performance...

Le mode interpréteur de Java SE a été complètement mis de coté depuis la version 1.2 qui date justement de 1998. Et depuis le compilateur JIT n'a cessé d'être amélioré.

Ce que veut dire par là c'est qu'un programme qui tourne sous machine virtuelle avec un compilateur JIT n'a pas à envier un programme natif !

a++

[gorgonite]

euh le cout de l'objet java qui prend moins de place que l'objet c (si on considère que les objets existent en c... ), et son temps de chargement qui est inférieur... il fait preuve d'une certaine mauvaise foi sur ce coup-là

je sais pas qui est ce type, mais il doit compter ce que consomme la JVM pour faire le chargement "paresseux" de la classe et de l'objet... et oublier le chargement réel, qui peut intervenir bien plus tard

[gorgonite]

J'ai eu le temps d'y jeter un coup d'oeil... c'est très intéressant mais cela ne parle pas de compilation JIT mais d'interprétation de bytecode ! Or il y a quand même un fossé énorme entre les deux en terme de performance...

Le mode interpréteur de Java SE a été complètement mis de coté depuis la version 1.2 qui date justement de 1998. Et depuis le compilateur JIT n'a cessé d'être amélioré.

Ce que veut dire par là c'est qu'un programme qui tourne sous machine virtuelle avec un compilateur JIT n'a pas à envier un programme natif !

ben on en reparlera quand tu regarderas de plus près l'intérieur de l'usine à gaz...

je t'ai cité un papier de référence sur les machines virtuelles... qui soulignent certains aspects qui ralentissent le code, et qui restent vrais avec la compilation JIT
à ma connaissance, la machine virtuelle java ne compile pas systématiquement le bytecode... premier point, qui implique que si l'on ne fait pas de boucles trop grosses et autres trucs du style, ce papier continue de s'appliquer. ensuite, le coup d'une compilation JIT est certes plus faible que celui d'une compilation native, mais ne peut effectuer que des optimisations locales !!! sans par exemple, déterminer le graphe des états accessibles pour supprimer le code mort (qui est peu couteux vu le chargement paresseux des méthodes et attributs des objets et classes Java, mais non nul )

[Mat.M]

euh le cout de l'objet java qui prend moins de place que l'objet c (si on considère que les objets existent en c... ), et son temps de chargement qui est inférieur... il fait preuve d'une certaine mauvaise foi sur ce coup-là

c'est normal Gorgonite ! la personne qui a rédigé cette article est un pro Java puisqu'il bosse chez Sun il va pas dire du mal de son produit
Ceci dit bien que l'article soit intéressant je suis extrêmement sceptique...

[Mat.M]

C++ aussi possède un système d'exception... je crois que je n'ai pas bien compris ce que tu voulais dire par là...

Pourrais-tu préciser ??? Le passage du GC peut être long dans certain cas, mais dans la plupart des cas il est plus performant qu'une gestion à la main de la mémoire...

eh bien pour chaque code opération en Java, par exemple s'il ya une pseudo instruction comme "charge registre" ou "charge pile variable tel valeur" eh bien on vérifie sil la valeur est cohérente ce qui n'est pas effectué en C/C++ et autres langages "code natif" , je l'accorde.

It is possible for Java code to be faster than C. For example, allocation in the Java language is already much faster than it is in C. Java programming enables optimizations not possible in C because C leaves so many important factors, such as allocation and thread management, to libraries.

C'est faux ! C'est pas le code en C qui fait les allocations mémoires c'est l'OS.
S'il ya des ralentissements c'est parce que la mémoire est fragmentée ( système de pagination )
Sur ce coup-là Java peut tricher parce qu'une appli Java va demander plus d'allocation que nécessaire et verrouiller la mémoire demandée.

Pour les threads c'est totalement archi-faux ( c'est vraiment de la mauvaise foi et de la méprise d'un soi-disant gourou de Java) parce que pour tout programme qui s'exécute que ce soit en code natif ou via un "framework" ( .NET ou bien JVM pour Java ) ,c'est le système d'exploitation qui gére le multitache et les threads.

Donc votre Brian Goetz essaie de vendre un truc sur l'incrédulité des gens...( normal il est évangéliste après tout )

[adiGuba]

je t'ai cité un papier de référence sur les machines virtuelles... qui soulignent certains aspects qui ralentissent le code, et qui restent vrais avec la compilation JIT

Perso j'y voit plutôt des détails d'implémentations pour des optimisations d'interpréteur de bytecode... Il ne parle pas vraiment de JIT...

à ma connaissance, la machine virtuelle java ne compile pas systématiquement le bytecode...

Si je ne me trompe pas, la JVM server compile un maximum de code (et lorsqu'on parle de performance en Java on parle de la JVM server).

déterminer le graphe des états accessibles pour supprimer le code mort

C'est plutôt le travail d'un analyseur de qualité de code que d'un compilateur non ? Les compilateurs C++ font cela ?

eh bien pour chaque code opération en Java, par exemple s'il ya une pseudo instruction comme "charge registre" ou "charge pile variable tel valeur" eh bien on vérifie sil la valeur est cohérente ce qui n'est pas effectué en C/C++ et autres langages "code natif" , je l'accorde.

J'avoue que cela me dépasse un peu... De quel cohérence parles-tu ?

C'est faux ! C'est pas le code en C qui fait les allocations mémoires c'est l'OS.
S'il ya des ralentissements c'est parce que la mémoire est fragmentée ( système de pagination )
Sur ce coup-là Java peut tricher parce qu'une appli Java va demander plus d'allocation que nécessaire et verrouiller la mémoire demandée.

Le GC gère lui même sa mémoire par bloc, et redimensionne cette mémoire au besoin. Ainsi par exemple si tu crée 500 objets, au lieu d'y avoir 500 allocations mémoires il n'y en aura que 5 ou 6....
Il ne triche pas c'est justement un des objectifs du GC.

Pour les threads c'est totalement archi-faux ( c'est vraiment de la mauvaise foi et de la méprise d'un soi-disant gourou de Java) parce que pour tout programme qui s'exécute que ce soit en code natif ou via un "framework" ( .NET ou bien JVM pour Java ) ,c'est le système d'exploitation qui gére le multitache et les threads.

Sauf que pendant longtemps la JVM utilisait son propre système de thread ("green thread") sous Linux/Unix car le système de thread qui y était implémenté était peu performant (car chaque thread était représenté par un processus)...

Donc votre Brian Goetz essaie de vendre un truc sur l'incrédulité des gens...( normal il est évangéliste après tout )

Et d'autres restent un campé sur leurs positions en repoussant tout de la main...


Je crois qu'on arrivera pas à de mettre d'accord donc tout cela ne sert à rien

bye bye

a++

[robert_trudel]

il faut savoir ce qu'on veut comparer

si on veut directement du java qui est compilé avant l'exécution, il y a gcj et autre produit commercial

sinon oui les programmes en c++ consomme généralement moins de mémoire que ceux écrit en java, mais ce derniers a un énorme avantage, c'est son gain de productivité

il y a aussi les processeur un peut fait pour java, par exemple ceux de azul.

personnelement, je crois que l'emplois du C++ est de moins en moins nécessairement étant donné les gains fait en développement et le niveau de performance atteint avec les derniers JVM.

Java a d'ailleurs fait un énorme progrès dans les systèmes embarqués.

[Thorna]

Je me demande, en lisant les dernières pages, s'il ne faudrait pas revenir à la question initiale et aux 2 ou 3 premières réponses qui ont été données en page 1 de cette discussions!
Votre débat est intéressant mais vous comparez deux choses qui ne sont comparables que dans quelques petits pourcents des cas.
Les ordinateurs d'aujourd"hui sont infiniment plus puissants et rapides que ceux d'il y a seulement quelques années (le post date de 2002 !), et l'interprétation ou la compilation JIT ne pèsent rien dans les applications courantes que nous utilisons tous les jours: je veux dire, par exemple:
- l'Interface Utilisateur de n'importe quel produit (que ce soit un OS, que ce soit un tableur, un traitement de texte etc.), qui passe l'essentiel de son temps à attendre l'utilisateur et n'a pas besoin de le faire rapidement...;
- un browser, qui est lent du fait de l'internet ou de l'intranet, et non du fait de son langage de programmation;
- un lecteur de mail, pareil;
- un Oracle/SQL/SyBase, bref un système de base de données dont la rapidité dépend quand même en grande partie de celle du disque et/ou de l'organisation des données dans la base;
- etc.
Dans toutes ces utilisations, je ne vois pas en quoi un code interprété (si ça existe encore, je laisse le soin aux spécialistes de se battre à ce sujet) ou compilé à la volée si nécessaire (s'il est utilisé, ce qui produit là aussi quelques améliorations) pourrait poser problème.
Il reste encore quelques grands types d'utilisation courante (si on peut dire...), que sont par exemple les jeux vidéo, où la recherche de la performance est maximale... du point de vue graphique, ce qui est le boulot de la carte vidéo; ou des processus de commande/contrôle en temps réel où, éventuellement, on peut parfois (mais pas tout le temps) parler de nécessité d'une vitesse maximale et où certains préféreront sans doute C++.
Notez que C#, qu'on a cité il y a quelques pages, le plus à la mode des langages du jour, que ce soit embarqué ou non, est identique à Java dans ce qu'il utilise aussi la compilation JIT. Et qu'on l'utilise de plus en plus partout, c'est sans doute un signe

[BebertSHINE2004]

Le C++ et le Java ne sont pas de la même génération, Java fait intervenir
de nouveaux concepts objets (Design Patterns). Il faudrait comparer le Java plutôt avec le C# (qui est son demi-frère dont le papa est Microsoft).

Personnellement, j'utilise le C++ pour des applications qui demandent de la performance (et encore ça devient très discutable avec les dernières JVM), par exemple des jeux. Le C++ est un langage proche du code machine, il a une syntaxe plus compliquée, mais une fois que l'on a bien compris l'utilisation des différents opérateurs, on produit du code trés performant. Et puis, ça nous permet de comprendre comment fonctionne le compilateur, en Java, la syntaxe est plus simplifiée, de ce fait tout est masqué (références, pointeurs, tas, pile,etc..., les bases de la programmation se perdent...)

Le java est très satisfaisant pour des applications multi-tiers, l'utilisation de base de données. Java est bien sûr tres portable (vous pouvez aussi bien écrire un code pour un pc de bureau que pour votre machine à laver ou téléphone !!).

Pour moi, cette comparaison n'a pas lieu d'être, il faut apprendre le C++ ET le Java...OU le C++ ET le C#. Pour premier langage je recommande Java ou C#.

[FloMo]

Franchement, pour avoir utilisé les 2, je dis C++ sans hésitation. Avec une API comme QT4, il est possible de développer très rapidement une GUI et simplifier le code de manière portable. Il y a un bon designer. Les exécutables sont très performants. La documentation très bien structurée. Le code léger. Ca s'interface facilement avec d'autres bibliothèques.
Et pour ceux qui diront que QT4 est payant, je précise qu'il l'est si on fait du code payant, mais que lorsque le code est sous GPL, QT4 est utilisable librement (sous tous les OS maintenant).

Le couple C++ et QT4 dépasse très largement Java en terme de performances, de rapidité de développement et d'interfaçage avec d'autres bibliothèques (OpenGL, SDL, VLC).

[hugo123]

Le C++ et le Java ne sont pas de la même génération, Java fait intervenir
de nouveaux concepts objets (Design Patterns).

Je ne vais pas participer a cette discussion puisque j'utilise les deux et que cette discussion me parait inutile, (le choix s'imposant de lui même selon les situations), mais je releve juste cette phrase.
Un design pattern c'est un patron de développement en traduction littérale, et en pratique c'est des designs qui ont fait leurs preuves (par exemple l'un des plus connus, le singleton). Donc je ne vois vraiment pas en quoi le fait de conceptualiser est propre a un langage ?!?
Tu conceptualises/rationnalises pas en C++ toi ? ^^

[gd_dev]

C++ vs Java est à mon avis un débat qui n'a pas lieu d'être. Si vous débutez, il faut apprendre soit l'un, soit l'autre, ou pourquoi pas C#. L'important c'est d'apprendre, au travers du language, les conceptes clés des infrastructures que vous aimeriez programmez (Drivers, Jeux, CRM, Client - Serveur, etc... ) et les mode de programmation (structuré, objet, agent, UML, etc..).

Quand vous saurez modéliser vous ferez alors le choix de la technologie la plus appropriée.

Je pense que l'aire du choix du language est dépassée. Si vous savez programmer en C++ vous n'aurez aucune difficulter à apprendre Java ou autre chose. La difficulter d'apprentissage sera au niveau des librairies que ces languages proposent et à ce niveau je dirais que nous faison un mêtier d'artist.

En effet, à un moment donnée vous devez décider d'investir du temps dans l'apprentissage de librairie (Swing, dot.net, ...) et ce choix augmente votre potentiel ou vous rend marginal. Un mêtier d'artiste quoi.

Microsoft avec dot.net propose une librairie unifié qui nous libère de ce choix.
Mais ce choix ne peut pas être fait au détriment du produit que nous allons construir.

En résumé, les choses changes et l'important est de monter dans le train, par la porte ou par le toit, et de ne pas s'assoir trop longtemps.

A mon avis, les choix sont dépendant du problème et c'est difficile de généraliser dans le sans où on choisie la technologie en fonction des données technique mais aussi des délais de livraison et du coût.

C'est un problème d'optimisation.

[bobuse]

Franchement, pour avoir utilisé les 2, je dis C++ sans hésitation. Avec une API comme QT4, il est possible de développer très rapidement une GUI et simplifier le code de manière portable. Il y a un bon designer. Les exécutables sont très performants. La documentation très bien structurée. Le code léger.

À noter le développement de QtJambi par Trolltech, les bindings QT4 pour Java

[Kawelito]

en premier langage, moi j'recommande le C++ ... bien qu'ayant une préférence pour JAVA. Mais c'est parceque je suis feignant ! ... j'crois qu'ça résume bien la situation !

le C++ t'apprend tout de suite à être beaucoup plus carré. Bien que d'autres en diront le contraire, on peut quasiment faire la même chose dans les 2 langages. En Java, c'est très vite la fête à la saucisse. Et même en Java 6, le garbage collector fait un peu ce qu'il veut. Vous m'direz qu'y'a des DesignPatterns efficaces contre ça ... mais ces Patterns étaient déjà utilisés sous C++ pour la plupart !

après, reste à savoir ce qu'on veut faire ! j'me vois pas aujourd'hui faire du client léger en C++. Les archi J2EE sont bien assez efficaces comme ça même si j'suis faché ac JBoss/Tomcat et que .NET 2.0, ça a de la gueule ! en plus, chez Avanade, on développe des nouveaux Frameworks (qui vont surement rester interne ) qui ressemblent trait pour trait à ceux de J2EE (Struts, Hibernate, etc ...) ! et puis la politique de Microsoft où "on copie et on refait en mieux" ... ben ça peut être que mieux !

bref ...

C++ !!

[kpouer]

C++ est plus complet (on peut a peu pres tout faire avec), plus performant (quand correctement concu et code), plus generaliste(bien que en principe objet, on n'est pas oblige de faire de l'object avec), plus puissant (template, ...), plus complet (il vit depuis longtemps et possede de tres nombreuses librairies, standard ou non). C'est egalement un langage tres complique et tres sujet a l'erreur et a l'introduction de bogues.

Java est plus facile a apprendre et utiliser, plus portable, plus objet.

Dans les deux cas il peut y avoir des problemes de compatibilite. Au niveau C++, c'est surtout lie a la portabilite (si tu code du C++ standard), mais le code est ensuite rarement compatible, sur une meme machine , d'un compilateur a un autre. Au niveau Java, il y a des problemes de compatibilite et support entre les versions. La version 2.0 de Java n'est pas supportee partout et par tous.

Juste une chose : tu dis qu'il y a en C++ plus de librairies, ca j'en suis pas bien certain, mais une chose est sure, c'est qu'elles sont très inégales, et peu facile a trouver contrairement a java qui apporte en standard un bon paquet de librairies, et qui ensuite a des groupes comme apache qui hébergent des tas de librairies de qualité. Ca aide beaucoup a trouver ce qu'on veut.

Quant a la version 2.0, c'est un peu obsolète, on en est a la 6.0 là. J'imagine que tu veux parler des applets et de Windows qui a souvent une jvm 1.1. Mais c'est en train de changer car heureusement Microsoft n'a plus le droit de distribuer sa JVM.

Et enfin pour ce qui est de la rapidité du langage, c'est un peu plus complexe que ce que tu affirmes.
Prend un simple exemple de md5. En java il est 2 fois plus rapide que le md5sum de linux. Ensuite c'est vrai que tu peux optimiser a mort ton md5 en C et tu ira encore plus vite que java, mais tu auras perdu beaucoup de temps.
Bref dans beaucoup de cas il est faux de dire que le C/C++ est plus rapide que java car ca dépend énormément du développeur derrière et du type de projet. C'est sur que pour écrire un driver ou un moteur 3d le C++ sera plus adapté. Mais pour écrire un traitement de texte pas sur du tout que le c++ soit plus efficace

[smarties]

JAVA :
- plus simple que C++
- Documentation plus accessible
- Multi plateforme
- GUI facile a mettre en place

J'aime aussi c++ pour les raisons suivantes :
- natif donc plus rapide que java a l'execution
- gestion de la memoire
- pour les GUI, il faudrait que j'essaye des librairies specifiques (GTK...) car WINAPI

[Luc Hermitte]

Le C++ et le Java ne sont pas de la même génération, Java fait intervenir de nouveaux concepts objets (Design Patterns). Il faudrait comparer le Java plutôt avec le C# (qui est son demi-frère dont le papa est Microsoft).

Quoi ?
OK. Achete le GOF95, ou les bouquins de Coplien, regarde les exemples et dis-moi dans quels langages ils ont été écrits. (et bonne chance pour trouver une seule ligne de java)
Bien que des personnes aient tendance à utiliser le terme pour tout et n'importe quoi (e.g. le dispose pattern), un pattern est sensé être une solution générique qui transcende les langages.

Quant à Java, il ne fait intervenir aucune nouvelle notion OO. Bien au contraire, il en a moins qu'Eiffel ou même C++. Ses apports -- générationnels est un bien grand mot -- tournent autour de la JVM et de la richesse de sa bibliothèque qui vient en standard.

[kisitomomotene]

Franchement, pour avoir utilisé les 2, je dis C++ sans hésitation. Avec une API comme QT4, il est possible de développer très rapidement une GUI et simplifier le code de manière portable. Il y a un bon designer. Les exécutables sont très performants. La documentation très bien structurée. Le code léger. Ca s'interface facilement avec d'autres bibliothèques.
Et pour ceux qui diront que QT4 est payant, je précise qu'il l'est si on fait du code payant, mais que lorsque le code est sous GPL, QT4 est utilisable librement (sous tous les OS maintenant).

Le couple C++ et QT4 dépasse très largement Java en terme de performances, de rapidité de développement et d'interfaçage avec d'autres bibliothèques (OpenGL, SDL, VLC).

Le problème c'est que ST4 n'est pas standard. Et c'est ça le pb de C++. La bibilothèque standard est pauvre!!, et quand il y a pas de standard, on met plus de temps à maintenir du code ecrit dans une bibliothèque qu'on ne connait pas (il est peu probable par exemple que vous puissiez rapidement maintenir un code ecrit en MFC, étant donnez que votre biblio est QT4). Alors qu'en Java, ecrivez votre appli en swing, et il sera facilement maintenable par n'importe quel developpeur GUI Java.

[adiGuba]

Quant à Java, il ne fait intervenir aucune nouvelle notion OO. Bien au contraire, il en a moins qu'Eiffel ou même C++.

Il a surtout une approche beaucoup plus simple et différent de l'objet que le C++ (je ne me prononce pas sur Eiffel que je ne connais pas) :

• Méthode virtuelle par défaut.
• Pas d'héritage multiple.
• Notion de constructeur de copie quasi-absente, au profit de l'utilisation de classe immuable.
• Pas de surcharge des opérateurs (mais est-ce bien de l'objet ?)

A mon sens c'est plus une différence de philosophie et on ne peut pas vraiment dire que l'un est plus complet que l'autre ou plus aboutis...

La version 2.0 de Java n'est pas supportee partout et par tous.

La version 2.0 (ou plutôt 1.2) est supporté par toutes les JVM supérieur, bref par toutes les JVM modernes (la 1.2 date de 1998).

Seul Microsoft s'est éterniser avec sa VM 1.1 obsolète et non conforme...


La compatibilité ascendante (le vieux programme marche avec la nouvelle JVM) est assurée de version en version (même s'il peut y avoir des bugs ou des cas particulier où la compatibilité peut être perdu).

a++

[mat360]

Je ne vais pas rentrer dans la comparaison intrinsèque des 2 langages (je connais très peu le C++) mais le point suivant n'est pas à négliger:
- les offres d'emploi centrées sur Java sont beaucoup plus importantes que celles centrées sur le C++


De fait, Java est actuellement beaucoup plus utilisé et je ne vois pas le C++ remonter la pente de ce côté là. C# semble un concurrent beaucoup plus sérieux pour Java.

Donc à choisir pour un débutant qui veut faire de la programmation son métier: le Java ou le C# s'il a la fibre M$, à moins de vouloir travailler dans des domaines spécifiques (jeux, temps réel, ...) où le C++ domine.