Discussion :

[toutatafr]

Bonjour,

Ayant un grand nombre de JPanel à imprimer, je souhaite libérer des ressources après l'impression de chaque JPanel.

Voici en résumé à quoi ressemble le code:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
// l'appelle de print invoquera la méthode d'impression de monJPanel
try { pj.print(); } 
catch (PrinterException pe) {;}
// l'impression est terminée donc je libère le panel:
monJPanel.finalize();
monJPanel = null;

Mon problème est le suivant:

• soit je ne libère pas monJPanel et tout s'imprime correctement jusqu'à ce que je tombe en out of memory.
• soit je libère monJPanel mais j'imprime alors une page vierge car je le libère visiblement trop tôt.

Ma question est la suivante:

• existe-t-il un évènement à trapper qui permet de savoir que l'impression est terminée?

Question subsidiare:

• Pouvez-vous m'indiquer un tutoriel précis sur la façon dont java traite cette méthode print qui visiblement s'exécute dans un thread indépendant?

Pour info:

• Je n'ai pas trouvé de listener approprié (peut-être ai-je mal cherché? surement du reste puisque je n'ai pas trouvé de solution!)
• J'ai essayé de tester le retour de la méthode public int print(Graphics g, PageFormat pf, int pageIndex) en attendant le NO_SUCH_PAGE (mais ce n'est pas concluant)
• La seule solution que j'entrevois serait de tester le hashcode() du monJPanel utilisé dans la méthode public int print(Graphics g, PageFormat pf, int pageIndex) et de le libérer quand la valeur du hashcode() change (et donc qu'on commence l'impression du monJPanel suivant). Mais ça reste de la bidouille empirique...

Merci de votre aide

[tchize_]

vous avez juste à mettre le panel éventuellement à null. Le GC fera son boulot en temps et en heure. Si le panel n'est pas nettoyé, c'est que vous gardez ailleurs une référence sur ce panel. on appelle JAMAIS les méthode finalize soit même, elle sont destinée au gc, pour etre appelées quand l'objet est libéré.

[hwoarang]

Salut,

Si je me rappelle bien les tests que j'avais fait à l'époque, la fonction void print(Graphics graphics, PageFormat pageFormat, int pageIndex) est appelée quand tu fais printJob.print()

Autrement dit, au retour de printJob.print(), la tache est deja terminée. Par contre, comme précisé precedemment (ainsi que par la javadoc), c'est le garbage collector qui appelle finalize. Il faut simplement mettre ton jpanel à null et t'assurer qu'il n'y a plus de reference sur lui (s'il est inclu dans un autre container, ne pas oublier le remove).

Au passage, je ne sais pas si tu connais mais il est possible de lancer la machine virtuelle avec l'argument -Xmx pour augmenter la memoire allouée à celle-ci et eviter les out of memory.

a+

[toutatafr]

Merci pour vos réponses

Pour être plus précis, je n'appelle pas la méthode finalize(), mais finalizeMe() qui se contente de mettre à null tous les attributs du JPanel:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
  public void finalizeMe() {
    // planbay et selection sont aussi des extends JPanel dont la méthode finalizeMe() met à null les attributs
    selection.finalizeMe();
    planbay.finalizeMe();
    selection = null;
    planbay = null;
  }

Je savais qu'on pouvait allouer plus de mémoire à la JVM, mais il me semble que ce n'est pas très propre (est-ce une méthode courante?) et je préfèrerais comprendre où est mon erreur.

Si vous avez d'autres pistes je suis preneur.
Je vais déjà m'assurer de nouveau qu'aucun autre composant ne fait référence à monJPanel.
Merci

[tchize_]

vous ne devriez justement pas avoir besoin de mettre à null les attributs du panel, il seront libérés en meme temps que le panel le sera. Ce que vous faite est une bidouille pour retarder le problème (vous allégez le poids de l'objet qui traine en mémoire, alors que le problème est justement d'éviter qu'il traine).

Bref, retirer les références au panel. Et au printerJob, qui garde une référence sur le panel que vous avez passée via setPrintable.

[hwoarang]

Je savais qu'on pouvait allouer plus de mémoire à la JVM, mais il me semble que ce n'est pas très propre (est-ce une méthode courante?) et je préfèrerais comprendre où est mon erreur.

Ca n'a rien de "sale". Ca depend de l'utilisation. Si le nombre de jpanels est connu à l'avance, il n'y a rien de problematique a augmenter la taille memoire pour pouvoir les gerer.
Maintenant, si les jpanels sont potentiellement illimités et temporaires, c'est sur qu'il est mieux de les liberer après usage...

Mais sur le principe, c'est pas choquant d'augmenter la taille memoire quand on en a besoin...

[bouye]

Ce qui est choquant c'est que malgré les améliorations apportées a Java 1.5, il faille encore faire cela manuellement.