Kevin Kofler (./3907) :
Le Java est moins puissant que le C++

La phrase que l'on voit typiquement quand on parle de langage de programmation, qui n'a aucun sens, ou du moins un sens très différents suivant les personnes :
- La capacité de faire des chose en peu de lignes de codes (Perl est tès puissant)
- La capacité de faire de la métaprogrammation avancée (LISP est très puissant)
- La capacité de faire du code dégeu qui a l'air de marcher ( JavaScript est très puissant)
- La capacité de faire un code dont on a une idée de comment il va être compilé (C est très puissant)
- La capacité de faire des choses avec un minimum d'apprentissage (Go est très puissant)
- La capacité de faire ce que fait mon langage préféré (mon langage préféré est très puissant)

Kevin Kofler (./3909) :
Le GC fait que tu dois fixer un seuil de mémoire arbitraire à partir duquel libérer la mémoire, donc tant que tu es en dessous du seuil, le programme en consomme de plus en plus sans rien libérer, et si tu le dépasses, plus rien ne marche (ça commence à passer tout le temps dans le GC et, si jamais ça sort de la boucle, ça finit avec une exception "Java heap space" ("exhausted", mais ce n'est pas écrit explicitement dans le message de l'exception)). Du coup, tu ne peux pas utiliser de manière efficace la RAM de ta machine: soit tu bouffes toute la RAM pour rien (seuil trop haut), soit le programme plante alors qu'il resterait plein de RAM dans la machine (seuil trop bas).

Tout d'abord, c'est plus un soucis de la VM de Sun/Oracle et de OpenJDK qui en a hérité que du langage en lui même. Il y a des langes avec GC qui gèrent leur mémoire de manière sensiblement différente. Cependant, contrairement à ton intuition, si tu ne consomme pas trop de RAM, la VM d'Oracle libère cependant la RAM bien avant d’atteindre le maximum. Ce qui est trompeur c'est que c'est vrai qu'elle ne libère pas immédiatement et si tu alloue souvent, tu va atteindre le maximum avant qu’elle ai libéré assez, et a ce point elle sera obligé de libérer en effet.

Kevin Kofler (./3909) :
Un autre gros inconvénient est que le GC bloque l'exécution régulièrement à des endroits difficilement prévisibles, ce qui non seulement rend le Java inutilisable pour toute application temps réel (Ce n'est pas par hasard qu'il y a un gros avertissement de Sun/Oracle de ne jamais utiliser la technologie Java dans un réacteur nucléaire, ce serait le prochain Tchernobyl!),

C'est vrai que les pauses du GC sont un vrai problèmes pour certains types d'application. Je peux témoigner, pour avoir développé des jeux en Java, Le GC était un problème qui revenait régulièrement.

Kevin Kofler (./3909) :mais se remarque aussi dans la vie courante quand l'interface utilisateurs d'un logiciel freeze soudain pour une seconde ou deux parce que le GC a choisi de s'activer de nulle part.

Par contre, les freeze de l'IHM sont rarement un problème du au GC en lui même mais plutôt à une mauvaise utilisation des bibliothèques IHM, particulièrement Swing qui exigent de travailler d'une manière particulière qui est souvent mal respectée. Les appli Java qui respectent les règles n'ont pas ce genre du problème.

Kevin Kofler (./3909) :Et le troisième gros inconvénient est que le GC fait que tu ne contrôles pas quand le finalisateur de l'objet sera appelé. (Du coup, les objets pour lesquels c'est important nécessitent un close() explicit qu'on risque d'oublier, et il y a ce hack de "try with resources" qui fait que finalement, ces objets s'utilisent de la même manière qu'un objet RAII en C++. Sauf que tu ne peux pas oublier d'appeler le destructeur en C++ alors que tu peux oublier d'utiliser "try with resources" ou d'appeler close() explicitement en Java.)

Si on ne pouvait pas oublier d'appeler le destructeur en C++, ça se saurait.

Warpten (./3921) :
le try-with-resources c'est ni plus ni moins qu'une copie du using de C#.

Et le C# à la base n'est ni plus ni moins qu'une copie du Java.
Les langages s'inspirent les un les autres et c'est tant mieux (sauf quand ils s'inspirent du JavaScript).

Warpten (./3921) :
Au niveau des spurious wakeups du GC, en C# on a des mecanismes pour dire au GC de s'absenter pendant l'execution d'une routine je crois. En Java je connais pas.

A ma connaissance, ça n’existe pas dans le VM J2SE standard. On peut juste essayer de forcer les GC aux moments les moins critiques pour réduire le risque qu'ils arrivent dans les sections critiques.

Godzil (./3929) :

Uther (./3927) :
mais il reste généralement plus performant et maintenable que les langes a typage dynamique

##pointgodzil##

Pas du tout, je voulais dire par là que ce sont des outils à destination des jeunes programmeurs ##rattrapage_aux_branches##