Discussion :

[giloutho]

Bonjour à tous,

Je charge un fichier de waypoints que j'affiche dans un TableView et sur une carte OpenStreetMap dans un webview. Dans le code java, un clic sur une ligne du tableview "communique" avec le javascript pour centrer la carte sur le marker et afficher son nom.

Dans le code javascript d'affichage du webview, j'ai inséré une fonction qui permet, au clic sur un marker, de récupérer dans le programme java avec une classe Bridge, le texte affecté au marker. Cela permet de retrouver le waypoint dans le tableview et de sélectionner la ligne concernée.

Après quelques heures de suée, cela fonctionne nickel... Sauf... sauf que cela ne marche plus au deuxième chargement d'un fichier de waypoint !!! Plus précisément, cela ne marche plus quand je relance un loadContent du WebEngine.

Pas de problème dans le sens java -> javascript, un clic sur le tableview déclenche l'action javascript attendue. Par contre, dans le sens javascript -> java, cela ne fonctionne plus.

Dans mes recherches web, j'ai retrouvé cette réponse de Bouye.

un correctif à eut lieu sur le WebEngine pour éviter que ce dernier conserve une référence ad vitam eternam sur l'objet bridge passé ce qui provoque une fuite mémoire. Donc si tu ne conserves pas une référence dessus dans ta classe Java, cet objet bridge sera garbage collected à un moment ou un autre et donc tous les appels suivant échoueront car il sera null dans la partie JavaScript.

Je ne saisis pas trop le sens du si tu ne conserves pas une référence dessus dans ta classe Java

J'ai baladé l'instanciation de ma classe Bridge sans résultat... une idée ?

[bouye]

Ben que tu dois conserver une référence à ton bridge dans ta classe sinon ce dernier se fera garbage collecter à la 1ere occasion et donc cessera de fonctionner.

Ça fait quand même parti de principes de base de Java (la gestion automatique de la mémoire) mais comme ce genre de bugs qu'ils avaient introduit laisse à penser que non et que ça peut perdurer des plombes avant d'être corrigé, on oublie de le faire et donc quand ils corrigent leur fuite mémoire.... surprise : "a marche pu !". Sans parler que souvent avec le code spaghetti des UIs on a des références en dur "invisibles" cachées ici et là (ex : listeners) et on y prend pas garde.

Code :

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

1
2
3
4
5
6
7
8
9
10
class MaClass {
 
    private Bridge bridge;
 
    private void initializeWebView()  {
        [...]
        bridge = new Bridge();
        jsobj.setMember("java", bridge); 
        [...]
    }

PS : le même soucis se pose aussi avec les services ou même les threads. En général quand je poste du code sur les taches de fond, c'est pour des tests rapides et donc je ne crée pas de référence dure vers ce service / thread mais dans le cas de taches (très) longues, sans référence dure, le service / thread est garbage collecté et donc la tache peut se "perdre dans la nature".

[giloutho]

Merci Bouye pour cette réponse rapide et précise qui malheureusement ne résout rien.

Mon code correspondait exactement au pseudo code que tu as donné en exemple. En ayant lu ta réponse dans un précédent sujet, j'espèrais que quelque chose m'avait échappé.

J'ai fait varier le positionnement de l'instanciation de bridge, avant ou après le loadContent... Toujours pareil.

En continuant les recherches, je suis tombé sur un message qui rapportait exactement ce bug et qui à priori devait être fixé.

J'ai essayé de faire un new WebEngine à chaque fois nada...

La seule solution serait de refaire une nouvelle instance du webview, car si je ferme la fenêtre qui gère tout cela et que j'y reviens cela fonctionne. C'est au deuxième loadContent que cela ne marche plus. Je ne sais pas si serait très orthodoxe et est ce possible car je suis sur du FXML.

[bouye]

Merci Bouye pour cette réponse rapide et précise qui malheureusement ne résout rien.

Hum zut.

Quelle version du JDK utilises -tu ?

EDIT - remarque la page de bug que tu as listé ne laisse pas beaucoup d'espoir sur le fait que ca ne sera pas fix avant le JDK 11 et comme ils sont en train de réfléchir sur comment distribuer les binaires maintenant qu'ils ne font plus parti du JDK c'est pas gagné...

[giloutho]

Très bonne question... que je ne m'étais pas posée car je fais toutes les mises à jour sur ma machine (macOs) tant sur l'OS que sur netBeans.

C'est bizarre car le terminal me renvoie 1.8.0_111. Et si je vais sur le panneau Java de la configuration système il affiche : Java 8 161. configuration java à jour.

Désolé pour le hors sujet...

[bouye]

Sur macOS le JRE (/Library/Internet Plug-Ins et /Library/PreferencePanes) et le JDK (/Library/Java/JavaVirtualMachines) sont deux install complètement distincts (plus que sur Windows). Par défaut seul le JDK permet d'invoquer la commande java dans le terminal mais il est aussi possible d'invoquer celle du JRE si besoin (/Library/Internet\ Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/bin/java)

[giloutho]

Mise à jour du JDK... sans changement... Force est de considèrer que c'est un bug du webviewer...

Encore merci pour ta disponibilité et ta patience.

[bouye]

Pour supprimer les anciens JDK il suffit de supprimer les répertoires appropriés dans /Library/Java/JavaVirtualMachines. Coté JRE c'est comme Highlander, il ne peut y en avoir qu'un seul de toute manière.