Discussion :

[la.lune]

J'ai juste une question sur la meilleur manière de manipuler les fichiers FXML, et la scène. Est ce que la bonne façon c'est de créer une nouvelle scène lorsqu'on appel un nouveau fichier, qui est sensé nous fournir un ensemble de service à objectif commun(comme répondre à use case donné) sachant que possible(pas toujours) d'appeler une(des) portion(s) de fichiers par des includes dans le fichier à appeler?
Ou bien la meilleur façon c'est de consacrer un neod region comme contenu principale de notre interface, ce noeud est référencé sur le fichier fxml principale et que après on fait un clear pour enlever son contenu, afin d'appeler le contenu se trouvant dans un autre fichier FXML.
S'il y a une autre manière elle est la bienvenue, ou bien si ça dépend des cas, ça sera bien de nous éclaircir.

J'aurais aimé comprendre aussi côté cycle de vie de l'application, la libération de mémoire, et quelque idées sur la performance, Merci

[bouye]

Je ne sais pas. Il vaudrai probablement directement poster sur OTN en espérant que le concepteur du FXML y apporte sa réponse.

Personnellement j'utilise plutôt la seconde solution mais c'est car en 1.x changer de scène menait parfois a des comportement inattendus. De plus, si on veut faire des animations lors du changement d’écran, il faut alors bien sur conserver une scène unique.

Après toutes ces années, la gestion de la mémoire, reste pour moi, un problème d'importance en Java. Même en mettant la meilleure volonté du monde pour faciliter la nullification des références, les application restent bien trop gourmandes sur des postes client. De ce fait, je n'ai jamais pu considérer une application Swing ou FX comme légère a cause de la trop grosse consommation impliquée des qu'on affiche deux trois trucs a l’écran.

Souvent, en utilisant jmap et jconsole on voit bien que la faute en incombe au garbage collector qui ne fait pas correctement son boulot et n'est pas assez agressif dans sa libération.

D'un autre cote, la faute en incombe également aux didacticiels et cours de Sun, Oracle, la fac ou d'autres sites web qui évidement passent complétement sous silence la gestion de la mémoire par le programmeur.
A ce titre la session From Java code to Java heap: Understanding and optimizing your appl... de Chris Bailey l'an dernier était particulièrement intéressante même si trop courte.

[ame="http://www.slideshare.net/cnbailey/java-code-to-java-heap"]From Java code to Java heap: Understanding and optimizing your appl...[/ame]

Note: problème d’intégration, cliquer sur le titre du cadre pour accéder a la page contenant la presentation

Pour en revenir a FX, pour avoir une bonne gestion de la mémoire, Richard Bair a indiqué plusieurs fois sur le forum OTN :

• Il faut retirer les "hard"-listeners.
• Ou utiliser des WeakChangeListener, WeakInvalidationListener, etc. (l'API le fait en interne).
• Il faut de-binder les propriétés.

Ce qui revient de toute manière a insérer des methodes de nettoyage dans le code (on en profitera donc également pour vider les collections et nullifier les références)... ce que je fais déjà... et ce n'est pas suffisant en soit.
Évidement comme FXML et le contrôleur (avec tout ce qui est listener qui permettent d'invoquer les methodes spécifiées dans le FXML) c'est une peu la grosse boite noire, on ne sait pas trop ce qu'il en est.

Après, pour le moment je trouve que malheureusement, en 2.2, la gestion des CSS semble encore TRÈS gourmande en mémoire parfois (suite a des bugs?)

[la.lune]

Merci en tout cas pour ces éclaircissements

[la.lune]

Quel est l’intérêt particulier de faire qu'un contrôleur hérite d'une class de type neod région (qui est en générale la classe du neod région racine sur le fichier fxml) et le fait de le laisser le contrôleur juste implémenter un l'interface Initializable?
Bon je sais que les deux ne veulent pas dire la même chose, car avec l'héritage on aura accès aux méthodes par héritage aussi, que de les appeler via le neod en soi, mais je me demande l’intérêt particulier, est ce que techniquement ça possède un avantage, car j'ai des codes qui font cela. Car sans utiliser cette technique ça marche très bien.