J'ai une classe apparemment toute normale (public, pas abstraite, n'implémente pas de trucs bizarres), et j'ai voulu surcharger finalize pour afficher des informations de débogage à la fin. Mais voilà, ça n'entre jamais dans finalize. Je suis sûr qu'elle a été créee, car elle passe par un point d'arrêt que j'ai mis.
 

 
Elle est appelée comme ça:
 

 
Et n'est stockée dans aucune variable.
 
Le problème en soi n'est pas trop gênant dans mon cas car je peux le contourner facilement, mais c quand même bizarre...
 
Quelqu'un a une idée ?
 

j'ai eu le même coup il y a 2-3 jours... je prenais finalize() pour  un destructeur à la C++...
 
il faut virer tout référence vers ton objet ET passer un coup de garbage collector pour que finalize soit exécuté... mais pas immédiatement...
 
sinon, j'ai croisé une note dans la doc accompagnant le JDK sur une option de la JVM mais je ne l'ai pas retenue.

 
pareil, il doir rester une référence à ton objet ce qu'il l'empêche d'être traité par le gc...

Déjà, tu n'as aucune garantie que ça sera appellé : http://www.mantrotech.com/technolo [...] notes1.asp
 
Ensuite, il peut te rester des références desssus.
Enfin, si tu fous pas la pression sur le GC, il va pas GCiser.
 
edit : en éditant (pour virer le code de la citation), je viens de m'appercevoir que tu avait foutu au moins 2 références sur la pile.

Je n'ai jamais alloué mon objet à un attribut d'un autre objet, donc il ne devrait pas y avoir de références. Je l'alloue seulement à des variables locales dans les methodes, mais ça disparait quand la methode est terminée normalement.
 
Je veux bien qu'il ne l'execute pas tout de suite, mais quand le programme se termine, le GC devrait appeler les methodes finalize de tous les objets qui sont encore là non ?
 
Sinon, c'est peut-être la note de TBone qui fournira la solution

non, car il ne réagit pas comme les destructeurs C++

bah dans la doc à côté de la javadoc... c'est dans les zesplications des options de la JVM si je ne me trompe.

 
je rajoute un peu de notation :

 
 
pas avant que ce bloc là ne soit fini, il y a 2 réferences à ton instance sur la pile durant l'exécution de uneMethode, quand elle se termine, il en reste une (la variable).
 

 
 
dans ce bloc là, le gc peut passer après le retour de la méthode, mais pas s'il n'a pas de raison de le faire (un coup de pression lors d'une allocation ou une demande explicite).

finalize est appelée au moment du GC. mais le GC, en Java, il passe quand il veut ... même quand tu lui demande de passer, il passe si il a envie ... y a pas de garantie !
 
si tu veux vérifier, t'as qu'à faire ca :  
 

 
et encore, ca pourrait très bien ne pas garbage collecter

Ok, ben je fais autrement...
 
Sinon, le programmeur du jdk qui fournit une méthode qu'on peut surcharger mais on ne sait pas si et quand elle sera appelée, il avait quoi derrière la tête ?

 
 
Faut que MaClasse ait une tonne de variables d'instance, et réduire le seuil du GC, et ça devrait marcher.

 
L'idée qu'elle ne s'utilise que dans des cas super-précis et rares, j'ai même pas d'exemple en tête.
 
Si tu veux jouer avec le GC, les références faibles me parraissent plus intéressantes (tu peux par ex. faire un cache de taille varible dont la taille augmente s'il y a de la mémoire dispo et qui diminue si la pression augmente).

Coincidence ?
 
Y'a justement un article de JavaWorld sur les nouveaux algorithmes de GC dans java 1.4.1

 
T'as une URL ?¿?

t'as essayé http://www.javaworld.com ?  

 
Nan parce qu'au fin fond de l'Argentine, le net il est pas pareil qu'en France et vu la vitesse, c'est plus rapide de demander que de chercher.
 
edit : heu dire merci ne devrait pas m'arracher le gueule.
 
merci pour l'URL