Voila après quelques recherches infructueuses (peut être une mais le thread parlait de l'utilisation en memoire importante d'un gros Jtree) je viens vous demander si par experience vous avez deja rencontrer un tel probleme.
 
Pour des besoins fonctionnels, j'ai donc, plusieurs arbres liés sur des données en 3 tiers, affichés dans un CardPanel. Lorsque je navigue sur une clé, tous les cardPanel sont effaces, et un nouveau Jtree est affiché dans une nouvelle page du CardPanel.
 
Ce Jtree a un cellRenderer qui lui permet d'afficher au niveau des noeuds, selon le contenu des informations, une ou plusieurs icones.
 
Jusque la, tout va bien, le probleme arrive au bout de qqs navigations, ou la lenteur d'un même traitement se fait sentir, je vérifie la mémoire, paf, le process javaw augmente sans cesse, jusqu'a tout bloquer. Un coup de memory Profiler, me montrera que les si simples JPanels et JLabels construits dans le cellRenderer, me bouffent tout, et ne sont jamais collectés.
 
Ni une ni deux, je trouve un bon endroit pour faire, un System.gc(), mlais c'est pareil, alors je me fais un petit KillAllListners, et je place qqs removeAll qui vont bien (jusqu'a tous les Nodes du JTree a effacer), mais hélas, c'est pareil.
 
En gros, je ne vous demande pas directement une solution ( haha sauf si vous avez de la magie pure, je suis preneur ), mais plutôt si vous avez déja été confrontés à ce genre de probleme et la technique/méthode que vous avez employés pour vous en sortir
 
Merci d'avance !
 
 

Tu peut poster le code de ton CellRenderer ?

On ne fait jamais un System.gc() soi-même, surtout pas dans une interface graphique !!!!
 
On peut voir tout le code de la chose stp ? tu gardes des références où il ne faudrait pas.

concernant, la méthode, je suppose que tu n'utilises pas le renderer selon la recette préconnisée et que tu crées un nouvel objet à chaque rendering, ce qui serait complètement à l'inverse du pattern de la peinture au tampon.

Voici le code du CellRenderer qui me chagrine, le HistoryTree est le composant qui permet les navigations, et qui integre les CardPanels qui eux même integrent les JTree
 
Je viens du C++, et c'est vrai que depuis qqs temps je suis moins attentif aux histoires de memoires sous java, belle erreur .
 

bon, je te fais le topo.
 
tu construis un JPanel que tu renvoies à chaque coup de peinture (soit très très souvent, imagines un scrolling).
 
au moment de peindre le composant appelle getTreeCellRendererComponent, il accroche le composant renvoyé comme enfant de lui-même, le layout et fait la peinture. Et il ne le vire pas, dans l'espoir que tu vas le réutiliser.
 
D'autre part, il est très très fortement déconseillé (voire interdit) de créer un composant dans cette méthode on doit modifier toujours le même composant.
 
bref, ce mécanisme est un mécanisme de *réutilisation*, tu dois donc *réutiliser*.
 
voilou
 
des détails : je vois un doLayout(), un repaint() ça c'est pelle à clous. 1) ça risque pas de peindre tant que c'est pas aggrégé dans un autre composant 2) ça risque pas de layouter tant qu'on a pas aggrégé dans un autre composant (on sait pas encore la place disponible) 3) ça n'a rien à foutre là. On est dans une méthode qui doit être aussi rapide que possible on est pas là pour prendre le café.

+1

Effectivement si on a pas le droit de creer des objets la dedans, ça change tout, je n'ai plus qu'a me creer une chieé d'icones qui representent toutes les possibilites d'affichages, ou de les creer dynamiquement.
 
Merci de l'info

nan, tu peux les créer la première fois que tu en as besoin par exemple, mais tu dois réutiliser après.
 
D'autre part, pour les ciones, tu es libre, je te parle pour les composant.
 
on peut avoir une capture d'écran du JTree avant que tu le casses STP ? pour voir si on peu pas simplifier un peu.

Voila la bête
 
Les differents Tree sont liés par une action ( les fleches en gros ) qui ouvre le Tree lié sur le CardPanel voisin, on peut naviguer dans l'historique, cependant une navigation sur un champ fait repartir l'historique à zéro. Ca peut paraitre compliquer a utiliser, mais finalement c'est tres souple, d'autant plus que je n'ai pas eu le choix !
 

mouais, mets directement des JLabel dans ton tableau au lieu de simplement des Icones, ça me parrait le plus simple ...
 
utilise toujours le même JPanel.

J'ai compris le mécanisme ! J'ai comme vous m'avez conseillé, utilisé un seul et même JLabel/JPanel etc, et c'est beaucoup beaucoup mieux !!
 
Ils n'empestent plus la mémoire, et je peux faire beaucoup de navigation avant que la mémoire soit pleine a nouveau, mais cette fois ci ne n'est plus ma faute, mais le JUTreeNodeBinding qui me cree des mega octets d'objets non collectes
 
Je vais voir de ce cote la à présent !
 
Merci pour tout !