Discussion :

[gorgonite]

SVP, ne dites plus que le garbage collector est difficile à utiliser, lisez un peu et maitrisez le, tout simplement. Comme diraient mes tant regrettés profs : "c'est marqué dans la doc".

je connais bien la théorie des garbage collector, et je peux t'assurer que jusqu'à jdk v1.4, celui de Java était assez décevant comparé à ce qu'il est théoriquement (et fait dans certains projets académiques ) possible de faire.... je ne pourrais pas te dire pour les jdk v1.5 et jdk v1.6, car j'ai été un peu surchargé, et je n'ai pas suivi l'affaire....

donc il y a certainement beaucoup de paramètres qu'il faut savoir manipuler, et qui s'adaptent mieux à certain type d'applications... mais il faut aussi savoir que si l'utilisateur lambda doit étudier son code pour adapter le garbage collector, il va finir par trouver cela chiant, et repassera sur un garbage collector "par défaut", ou à un langage où l'on peut gérer explicitement la mémoire de manière "facultative" (c'est un des avantages de C# sur Java )


nb: au passage, pour ceux qui ont que DCOM utilisait un simple compteur de référence pour avoir quand libéré un objet distribué, on peut dire que Sun n'était pas trop à la ramasse à l'époque...

@the-gtm :
tu dis : "C'est sûr, et c'est pour ça que les développeurs Java ne font que des programmes simples et passent leur temps à maudir le garbage collector qui leur complique tellement la vie..."

--> Non mais il faut arrêter le chichon là hein Le garbage collector, c'est comme l'informatique : un informaticien compétent, curieux et prêt à s'investir saura l'utiliser. L'autre, celui qui ne regarde pas plus loin que le bout de son nez aura effectivement des souci et dira "pouaha, c'est nul".
Enfin, où diable as-tu vu qu'on ne faisant que des softs simples avec Java ?? On ne doit pas parler de la même dimension.

sa remarque était placé sous le signe de l'ironie... pourtant quelqu'un comme toi qui regarde plus loin que le bout de son nez aurait du comprendre rapidement

[epsilon68]

... donc le garbage collector convient à tout le monde ? pas de defaut ? de cas ou il se comporte mal ?

[the-gtm]

Ma remarque était effectivement ironique

Le garbage collector pose problème quand il crée des pauses trop longues pour l'application. C'est surtout génant dans l'embarqué (les pauses sont "aléatoires" alors qu'on a besoin d'un comportement déterministe), et dans les très grosses applis, par exemple un serveur J2E avec beaucoup beaucoup de mémoire.

Pour l'embarqué je pense que le C++ est de toute façon plus adapté, pour les serveurs il y a le GC concurrent qui fait quasiment tout le boulot sans bloquer l'application.

[epsilon68]

... et vous ne pensez pas du tout que entre deux pauses du garbage collector, votre programme peut utiliser largement trop de memoire ? jamais ? dans aucun cas ?

[kpouer]

... et vous ne pensez pas du tout que entre deux pauses du garbage collector, votre programme peut utiliser largement trop de memoire ? jamais ? dans aucun cas ?

C'est a mon avis un choix de Java de privilégier la vitesse d'exécution sur l'optimisation mémoire. Ce qui ne veut pas dire qu'on ne puisse rien faire pour améliorer les choses. Ce que beaucoup ont tendance a faire c'est se dire que comme il y a un garbage collector on se prend pas la tete sur l'optimisation mémoire, économiser les instantiations d'objets et tout, selon moi c'est une erreur

[FloMo]

A chaque nouvelle version de Java, on nous a promis les mêmes choses : plus de performances, plus de portabilité. Le constat est que Java est vraiment trop lent.

Personnellement, depuis que j'ai découvert l'API Qt4 couplée au C++, je trouve qu'elle n'a rien à envier à Java : les applications sont _réellement_ portables, les performances sont excellentes, l'API est riche et s'enrichit régulièrement. Le pied, quoi.

En plus, il y a même un designer pour créer les interfaces ainsi qu'un plugin pour Eclipse. Rien à redire.

[epsilon68]

C'est a mon avis un choix de Java de privilégier la vitesse d'exécution sur l'optimisation mémoire. Ce qui ne veut pas dire qu'on ne puisse rien faire pour améliorer les choses. Ce que beaucoup ont tendance a faire c'est se dire que comme il y a un garbage collector on se prend pas la tete sur l'optimisation mémoire, économiser les instantiations d'objets et tout, selon moi c'est une erreur

dans mon cas il fallait une memoire > 128 Mo (surement plus mais on n'a pas testé) et sinon apres modification, seulement 40 Mo

tu ne trouves pas qu'il faut quand meme s'en préoccuper ?
de toute facon, je n'avais pas le choix, il tournait sur une machine productive avec des resources extremement controlées ...
et tres honnetement 40 Mo c'est encore de trop, si j'avais pu le faire en C++, ca n'aurait pas depassé 4-5 Mo.

[kpouer]

A chaque nouvelle version de Java, on nous a promis les mêmes choses : plus de performances, plus de portabilité. Le constat est que Java est vraiment trop lent.

Personnellement, depuis que j'ai découvert l'API Qt4 couplée au C++, je trouve qu'elle n'a rien à envier à Java : les applications sont _réellement_ portables, les performances sont excellentes, l'API est riche et s'enrichit régulièrement. Le pied, quoi.

En plus, il y a même un designer pour créer les interfaces ainsi qu'un plugin pour Eclipse. Rien à redire.

Ca reste moins portable que java puisque tu dois compiler ton soft pour les différents OS alors qu'un soft java fonctionnera naturellement sur tous les OS.
Ca n'a l'air de rien, mais moi j'ai pas un FreeBSD ou un Mac chez moi pour compiler dessus par exemple au moins avec Java je n'ai pas ce soucis.
De plus la vitesse c'est très relatif, dans une application cliente, dans 90% des cas si elle est bien programmée en java ou en c++ on verra aucune différence car le facteur limitant c'est l'utilisateur.

dans mon cas il fallait une memoire > 128 Mo (surement plus mais on n'a pas testé) et sinon apres modification, seulement 40 Mo

tu ne trouves pas qu'il faut quand meme s'en préoccuper ?
de toute facon, je n'avais pas le choix, il tournait sur une machine productive avec des resources extremement controlées ...
et tres honnetement 40 Mo c'est encore de trop, si j'avais pu le faire en C++, ca n'aurait pas depassé 4-5 Mo.

C'est difficile a juger sans connaitre le contexte, mais si tu prend 40 Mo en Java alors que tu penses qu'en c++ tu prendrais que 5 Mo, c'est probablement qu'il y a des choses a optimiser dans ton dev java. Pour ma part je travaille sur un serveur en java qui recoit des paquets UDP (des centaines par seconde), les décode, effectue des traitements, en réémet, tout en étant un serveur sur lequel des clients peuvent se connecter pour récolter divers informations, et ca prend ptet 5 Mo.

[orelero]

Juste par curiosité, n'étant que amateur je me demande dans quelle circonstance un professionnel peut se creuser la tête à choisir l'un des deux langages pour travailler sur un projet ?

A priori je dirais que c'est trés rare.

[epsilon68]

Pour ma part je travaille sur un serveur en java qui recoit des paquets UDP (des centaines par seconde), les décode, effectue des traitements, en réémet, tout en étant un serveur sur lequel des clients peuvent se connecter pour récolter divers informations, et ca prend ptet 5 Mo.

5Mo c'est difficile à croire, mets donc ton server en charge, et tu verras que la JVM a tendance à s'etendre dans la memoire que tu lui as alloué.

La consommation mémoire excessive en Java est une chose reconnu. Meme si on arrive à vivre avec la plupart du temps, il y a des cas ou on est reellement embété c'est comme ca. Franchement ca serait decevant si vous continuiez à le nier. On ne va meme pas parler de la rapidité, vu que la plupart disent que c'est aussi rapide que du C .

[epsilon68]

Juste par curiosité, n'étant que amateur je me demande dans quelle circonstance un professionnel peut se creuser la tête à choisir l'un des deux langages pour travailler sur un projet ?
A priori je dirais que c'est trés rare.

non, ca depend de la tache, de l'importance des differents facteurs comme la memoire, la rapidité, et surtout de l'infrastructure du client.

[martel]

je pense que chaque langage a évolué, il suffit de voir dans le monde Java " Real Time Java" pour clouer le bec de ceux qui ne jure que par C++, et inversément allez voir les nouvelles librairies C++ pour faire plus facilement des applications solides et portables....

donc voilà il suffit juste de bien connaitre le langage et puis c'est tout faut par chercher plus loin.

[epsilon68]

a se demander qui devrait mieux connaitre Java

[knoum]

Juste par curiosité, n'étant que amateur je me demande dans quelle circonstance un professionnel peut se creuser la tête à choisir l'un des deux langages pour travailler sur un projet ?

A priori je dirais que c'est trés rare.

Bonjour,

Moi j'avais envie de développer en dotnet !

Au boulot on ne veut pas entendre parler de la technologique de chez Microsoft et on ne jure (les décideurs ?) que par Java.

Assez bizarrement je me retrouve aujourd'hui a coder aussi rapidement que lorsque je faisais du VB6 et a réaliser mes écrans avec tout autant de facilité. Merci NetBeans et Matisse.

L'ironie est que mes applications Java ne tournent et ne tourneront que sous Windows ce qui signifie que le critère de la portabilité n'est pas.

Quant aux performances je dois dire que je suis agréablement surpris car bien souvent les goulots dans une application sont liés à de "mauvaises" habitudes... héritage du lourd passé.

Le plus dur quant on impose une technologie autre que celle que l'on a envie d'apprendre est d'y trouver son plaisir. Une fois celui-ci trouvé le reste vient presque tout seul.

[epsilon68]

très honnètement j'aime Java mais je sais reconnaitre ses faiblesses quand elles sont visibles.

[knoum]

très honnètement j'aime Java mais je sais reconnaitre ses faiblesses quand elles sont visibles.

Bah tant mieux pour toi.

[epsilon68]

Bah tant mieux pour toi.

tu aurais mieux fait de justifier:

bien souvent les goulots dans une application sont liés à de "mauvaises" habitudes... héritage du lourd passé.

[knoum]

tu aurais mieux fait de justifier:

Tout d'abord il faut lire "héritage d'un lourd passé" et non "héritage du lourd passé".

Maintenant tu colles ce que tu veux derrière cette phrase.

En ce qui me concerne cela signifie que j'ai eu une mauvaise approche en développant en VB6.

Cela ne veut en aucun cas dire que je critique VB ou les technologies Microsoft. J'essaie seulement d'avoir un avis critique quant à la façon que j'avais de développer à l'époque. Si les langages évoluent il faut bien que les développeurs évoluent aussi.

Je pense que sans Java ou la POO - à travers un autre langage - j'aurais gardé cette façon de coder.

Ma réponse initiale était liée à la question de "orelero" et n'est pas en relation directe avec le sujet de cette discussion (C++ vs Java).

Sur ce bon développement.

[super_navide]

Il est incontestable que java est bcp mieux que c++ car il es plus équilibré
dans Java 1.5 on a

typage
garbage collector
type générique (mieux qu'en c++)
simple heritage de classe
heritage multiple d'interface
notion d'interface
creation de thread built - in
Meta model en lecture , pas de meta class
Closure (sorte de lambda ) en utilsant les classes anonymes mais très lourd syntaxiquement
pas de debuggage dans le même process
modification de classe a l'execution mais très limité (pour l'instant )
Appel dynamique de méthode
Portable
interfacage DLL complexe il faut développé une couche suplémentaire (
remarque il existe un framework payant pour interfacé une DLL sans dev supplémentaitre )

dans le C++ on a
typage
pas de garbage collector
type générique
heritage multiple de classe (possibilité heritage très riche mais très complexe)
thread en utilisant des APIs externes (plus lourd )
pas de Meta model en lecture , pas de meta class
pas de closure (sorte de lambda )
pas de debuggage dans le même process
modification de classe a l'execution impossible ou très très très limité
pas d'appel dynamique de méthode
Pas Portable
interface DLL sans dev supplémentaire

Pour n'importe quel appli Java si on a un problème de performance en terme de calcul on peut isoler le code et le mettre dans une JNI.

Si la taille de l'application de l'image est trop importante il y faut chercher a optimiser en utilisant des ClassLoader, et faire du profiling sur le code

De plus il y a des options pour partager les Classes entre JVM

Avant je pensait que java était lent et peut performant depuis que je développe avec java monkey engine je me dis que on peut - être un peut moin de performance mais on développe bcp plus vite.


C'est sur dans l'absolu le C++ est plus rapide et moin gourmand en espace mémoire mais la charge de développement est bcp plus importante....

[orelero]

Pour java il me semble que tu peux choisir entre un mode totalement interprété comme c'était le cas dans les anciennes versions (1.2 ?) et un mode compilé (JIT) qui optimise le code à la volée selon l'environement (dans certains cas, paraît que les perfs sont meilleurs qu'en C++) ce qui restera strictement impossible avec le C++.