Mais là encore, c'est un problème de runtime et moi je parle plutôt du langage, du point de vue du gars qui passe sa journée à l'écrire et de son efficacité à faire ce qu'on lui demande de manière fiable et propre sans trop pourrir la vie du codeur.
Kevin Kofler (./3909) :Frahcnement, j'ai jamais vu un programme bloqué à cause du GC, faut arrêter avec cet argument. En théorie OK, mais dans ce cas là, faut aussi arrêter les interruptions matérielles, etc
Un autre gros inconvénient est que le GC bloque l'exécution régulièrement à des endroits difficilement prévisibles
Quant au temps réel, c'est une contrainte très spécifique et d'une part il existe Real Time Java (connais pas), et surtout, je ne prétends pas que ça répond à tous les besoins : je dis simplement que le bashing contre Java est de mauvaise foi.
Kevin Kofler (./3909) :Certes, mais ça ne m'a strictement jamais posé problème, et je ne suis même pas sûr d'en avoir déjà écrit un.
tu ne contrôles pas quand le finalisateur de l'objet sera appelé.
Kevin Kofler (./3909) :Je ne vois pas bien en quoi c'est un hack, ça fait ce que ça dit et c'est plutôt pratique
il y a ce hack de "try with resources"
Kevin Kofler (./3909) :Il y a des warnings, et tu peux oublier d'écrire ton close dans le destructeur C++, oublier de libérer la mémoire, etc. Bref, oui, tu peux oublier plein de trucs, mais je ne suis pas certain que le Java soit moins sûr que le C++ sur ce plan là.
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.
Bref, pour résumer et éviter d'y passer des heures, les quelques inconvénients réels sont extrêmement contrebalancés par plein d'autres trucs nettement plus importants à mon avis, donc je doute que tu puisse me faire changer d'avis