bonjour,  
je suis en train de faire un explorateur de fichier java sur la base d'un JTree avec els modifications suivants :

• chaque noeud de l'arbre contient une JCheckBox ( comme expliqué dans cette méthode )
• chacun de mes noeud herite de DefaultMutableTreeNode avec deux variables d'instances supplementaire : un File et un long  

avec tout ca , mon appli s'arrete des que j'atteint les 42 000 noeuds ( pour une utilisation mémoire de pres de 80 Mo )  
y a t il un moyen de faire baisser cette utilisation ?  
 

 
 
EDIT : correction de la taille memorie

c normal, tu stockes les objets dans tes arbres..donc il fait la même taille que ton fs...crée un wrapper dont la méthode toString renvoit le nom du fichier, wrapper contenant uniquement le chemin de l'objet...le wrapper pèsera peanuts, et tu pourra en mettre bcp plus...

ok , je teste de suite  

hum, que contient ton File ? (donne un exemple de DefaultMutableTreeNode)
 
je pense avoir dit une connerie : si t'a qu'un file, t'a que la référence au fichier : tant que tu l'a pas chargé, il pèse rien...
 
sinon t'a essayé de mettre un paramètre à java pour qu'il t'alloue plus de mémoire pour l'application ?

je viens de tester  et ca ne amrche pas mieux avec des string : je viens de me faire la meme reflexion  
 
voici le debut de ma classe MyTreeNode :  

 et j'appelle ce constructeur de la maniere suivante :

 
je n'ai pas encore forcer la JVM a prendre plus de  memoire que par defaut
mais je prefererais eviter , vu qu' a terme je avis avoir a peu pres 5 a 10 fois plus de fichiers a mettre dnas l'arbre

et la taille de la VM ???
 
j'ai jamais les paramètres en tete, c -Xms ou qqc comme ca
 

40000 / 4 000 000 = 0.01 ce qui fait 10ko par objet...ca me semble gros...
 
-->tu peux pas mettre moins de chose dans le treenode ?

difficile : le aprametre size est tres long a recalculer dans le cas d'un repertoire , donc je suis obliger de le stocker  
et l'int etat fait parti de l'algo  
 
de toute maniere avec ces deux champs , ont ne doit pas arriver a plus de 10 octets / noeuds

je me demande si c pas la récursivité qui te bouffe tt la ram...
 

 
si par ex t'a un rep qui contient 10 rep dont chacun contient 10 rep dont chacun contient 10 fichiers, ca te fait déjà 1000 passages...dans un FS ca doit etre pire...
 
tu devrais foutre cette méthode hors du TreeSet, elle devrait même pas etre dans le dispatchEvent de Swing...

si j'ai un rep qui contient 10 sous repertoire
et que chacun de ces repertoires contient 10 fichiers , j'arrive a 111 appels de procedures ( 1 pour la racine, 10 pour les rep et 10*10 pour les fichiers ) ,non  ?
soit autant que de fichier
 
je peux difficielement passer en dessosu
 
de plus j'ai verifié ,je ne descends pas trop profond , donc  le cout de la recursivité est assez faible , meme si je vais quand meme tenter uen version derecursivée

 
tu peux detailler ?  
de totue maniere cette methode est static , je l'ai juste mise dans la classe de declaration de mon arbre pour simplfier le debuggage (avoir acces a l'arbre ainsi qu'au nombre de noeud )

Swing est monothreadé...donc tt opération ayant lieu dans swing est mise à la file dans une pile, et y'a qu'une seule thread qui la traite...si une opération prend 10 secondes à se réaliser, ta GUI est morte pendant 10 secondes (rien d'autre ne pourra se faire...)
 
c pe pas la raison du pb, mais c un pb que tu va avoir...le parsing que tu fais est lent par nature (il y a une question d'IO derrière)...donc pendant tt le temps de construction de ton arbre, ton appli est morte, tu peux te faire un café...
 
en relisant je vois que j'ai dit plein de conneries ...
 

ok, mais c c pas grave  
j'ai le temps ( c meme la seule chose qe j'ai pour cette appli )  
mais je penserai soit a faire un thread en background pour la construction de l'arbre , soit un splash screen

je viens de m'apercevoir que si je vire les JCheckbox , je passe a 29 Mo pour 42 000 noeud  
alors que je suis a presque 80 Mo avec ( je viens de refaire un pointage de l'utilisation memoire )  
il faut que je trouve qq hoe de moins gourmand que les JCheckbox , mais d'aussi pratique

Et si tu ne parsait que les repertoires qui sont affichés à l'écran, sans descendre dans tout les sous répertoires ?
Comme ca tu utilisera trés peu de mémoire, juste le necessaire à l'affichage.
Et puis lorsque l'utilisateur clique sur un noeud pour voir les sous repertoires a ce moment la tu cree tes objets.

mais l'appli plantera des que l'utilisateur cliquera sur develloper tout

Tu peut faire un pool d'objets JCheckBox pour resoudre ce problème

Arf...
Ben supprime cette fonctionnalitée  
Qui a envie de voir 42000 fichiers ?

-->privilégie le thread pour la construction de l'arbre (le splash c pour les faibles )
 
---> c clair que foutre un composant swing dans un node t'a le moral...surtout une checkbox je vois pas l'intéret : tu peux faire une sélection mutliple sur les noeuds d'un arbre (faut refaire le selectionListener, mais c possible)

c'est a dire ?  
qu'est ce que tu veux dire par un "pool" de JCheckbox : je borne l nombre max d eJCheckBox affichable ?

il me faut des CheckBox ( cahier des charges  ) pour pouvoir selectionner des fichier ( un peu comme pour emule lors du parametrage des fichiers partagés ) , donc je peux difficielement passer outre

Tu cree uniquement 2 instances de JCheckBox, une à l'état cochée, l'autre décochée.
Ensuite tu dans ton renderer tu retourne l'une ou l'autre instance en fonction de l'état qui doit être affiché, mais tu ne créé rien comme objet.

 
ca semble etre une tres bonne idée
 
si j'ai ben compris , la méthode getTreeCellEditorComponent me retourne le component ( dans mon cas une JCheckBox ) lors de la premiere selection d'un noeud  
c'est ca ?  
 
est ce que ca ne vas pas ensuite etre complique de lié l'etat de la checkbx a mon noeud ?

Ben fais voir le code du corps de ta méthode, apparement tu dois créer un renderer pour chaque noeud non ?
Et il sera peut etre preferable de separer tes 2 variables File et long pour les mettres dans un autre objet. Dans cet autre objet tu rajoutes un boolean pour dire si la checkbox doit etre cochée ou non.
Ensuite dans ton renderer tu regarde la valeur du boolean et tu retournes l'une des 2 instances de JCheckBox.

c'est exactement ca , je cree un rendreere pour chaque noeud  
ou plutot je cree une JCheckbox par noeud , que je retourne comme renderer
 
 

Pas bien !    
Ben essaye de faire comme je t'ai dis, c'est plus compliqué à coder mais tu vas utiliser beaucoup moins de mémoire en faisant comme ca puisque en fait tu va remplacer un objet JCheckBox par un boolean pour chaque noeud.

je suis d'accord avec nerisson : moins tu stockes dans chaque node, moins ce sera le bordel

vi , mais c vachement plus simple a coder
 
bon, je viens de tester , et j'ai une JCheckbox qui apparit quand je selectionne le noeud ,mais elle disparait des que j'en deselectionne un autre
 
la solution que je vais essayer de mettre en place :
a chaque noeud un JCheckBox que je cree uniquement si l'utilisateur fait un expand , et que je detruit a chaque collapse

note que c compatible avec mon idée de wrapper du début (sauf qu'en fait c ton node qui devient le wrapper) : tu stockes par référence, et pas par copie...

 
c de la lazy instanciation...c effectivement plus clean pour ton usage...

Poste un bout de code.
A mon avis tu as juste fait le pool de JCheckBox sans rajouter une variable boolean pour savoir quel JCheckBox afficher.

bon,je vais donc utiliser un TreeWillExpandListener

oui...y'a du code dans le javatutorial si ca t'intéresse

je crois que l'ai sous les yeux ( celui ou une popup demande si on veut bien fare un expand ? )

Faut faire gaffe avec seulement 2 JCheckbox.
Comment ça fonctionne pour le libellé d'un noeud de l'arbre si le TreeCellRenderer renvoie une des deux instances de JcheckBox ? le libelle du noeud sera le libelle du JCheckBox
 
Normalement, le libellé d'un noeud de l'arbre correspond au libellé du JLabel renvoyé par le DefaultTreeCellRenderer

d'ou la solution de lazy instanciation que j'utilise ( pour ne pas bouffer tro pde ram , mais pour afficher toutes les JCheckBox )  
 
surtout qu'histoire de bouffer encor un peu plus de ram , els JLabel des JCheckBox contiennent une icone

je vais dire une connerie, mais dans tout ça, t'as pas trouvé un endroit pour placer un flyweight pattern bien senti ?

je ne sais pas ce qu'est un flyweight pattern  
(search in progress ... )

intéressant ce pattern...