System.getProperty("user.dir") = NULL

Question

Salut,

J'ai une application qui doit vérifier la présence de fichier avant de rendre visible ses fenêtres. Si les fichiers ne son pas trouvé, l'application ce ferme. mais si ils sont trouvés l'application continue de démarrer normalement.

Dans ma classe main, j'ai un module qui vérifie l'existence des fichiers. Pour les trouver, je dois faire appel à System.getProperty("user.dir") afin de savoir avant tous où est mon application. Le problème c'est que System.getProperty("user.dir") me retourne une valeur NULL. Il est alors impossible pour moi de savoir où est mon application et par conséquence de vérifier l'existence de mes fichiers.

Que dois-je faire afin de savoir où ce situe mon application avant de charger les fenêtres?

Merci d'avance.

verdy_p · Answer

La lecture des propriétés de l'instance statique singleton associée à la classe System est une opération privilégiée. Si tu essayes de faire ça dans une applet, il est normal que cela retourne NULL: une applet ne peut accéder à cet objet (sinon violation possible de données privées de l'utilisateur).
Dans une applet il faut utiliser autre chose que le dossier "user.dir" pour stocker des fichiers de données: ces données appartiennent à la session en cours ou au site distant qui émet l'applet. Ce qui est manipulé n'est pas un "utilisateur" mais une "identité". Seul l'utilisateur lui-même peut accepter de transférer des données privées vers une de ses identités en ligne.
La solution pour une application: utiliser Java Webstart afin de permettre de configurer un espace de stockage propre à l'application à une identité. Les fichiers propre à un de tes utilisateurs seront stockés sur le PC de l'utilisateur dans un répertoire spécifique à ton application, sans posibilité de savoir ce qu'il y a autour. C'est l'utilisateur lui-même qui gère cet espace de stockage en acceptatn d'installer l'applciation et lui donner de l'espace de travail et de stockage.


Sinon il faudra passer par une installation classique d'application locale, et faire démarrer ton application par une instanciation locale de la VM (dans un raccourci du bureau par exemple) spécifiquement pour ton application. Ce qui "semble" marcher dans Eclipse est un répertoire "user.dir" qui n'est accessible que parce que Eclipse est démarré dans sa propre VM depuis un contexte ayant accès aux dossiers locaux de l'utilisateur.


Il me semble que ton problème est là : tu as effectivement ignoré ou oublié l'isolation des profils et données associées par les mécanismes de sécurité de Java, ou du navigateur hôte de la VM qui l'a configurée avec une isolation maximale. Dans une applet classique, le seul accès qu'offre la VM pour permettre à une application d'accéder à des fichiers locaux est d'utiliser le sélecteur de fichiers standard (qui nécessite une action intentionelle et explicite de l'utilisateur, pour qu'il retourne un objet "File" donnant accès au contenu d'un fichier local... et encore il y a des restrictions: globalement cela permet tout juste de faire des transferts de fichiers mais pas de travailler dessus).


Il faudrait que tu sois un peu plus explicite sur la méthode de déploiement utilisée pour ton application car tout est là, il me semble.

metalkev64 · Answer

Merci pour les explications très instructives.

J'ai trouvé la solution à mon problème. J'ignore le pourquoi, mais il semble que si je place System.getProperty("user.dir") avant la déclaration de ma fenêtres, cela fonctionne.

verdy_p · Answer

Attention quand même si cela fonctionne: est-ce que le chemin obtenu est relatif ou absolu? quel peut être l'influence des autres aPI que tu utilises et qui peuvent modifier ou initialiser l'environnement nécessaire.
Dificile à dire d'après ce que tu as indiqué ici. Une simple "déclaration de fenêtres" n'explique pas pourquoi "ça marche", mais le comportement de certains évènements générés par les fenêtres peut expliquer les choses. Comme on ne sait pas dans quoi tu déploies ton appli (serveur JSP, exécution purement locale par java.exe ou java web start, ou par un raccourci vers un fichier de commande qui prépare l'environnement nécessaire avant de créer la VM...) on ne pourra pas savoir ce qui se passe chez toi réellement.

metalkev64 · Answer

Effectivement je pourrai pas savoir le pourquoi si je ne donne pas de détail, désolé. 

Mon application est une application purement local, un jar exécutable. 

voiçi le code qui ne fonctionnait pas :

    public static void main(String[] args) {

        frmPrincipal FrmPrincipal; //Fenêtre principal de l'application
        FrmPrincipal = new frmPrincipal();

        Properties prop = System.getProperties();
        String Location = System.getProperty("user.dir"); //Retourne NULL

        GestionArgument(args, Location);
        FrmPrincipal.setVisible(true);
    }

et voici le code qui fonctionne :

    public static void main(String[] args) {
        Properties prop = System.getProperties(); 
        String Location = System.getProperty("user.dir"); //Retourne le chemin absolue 

        GestionArgument(args, Location);

        frmPrincipal FrmPrincipal; //Fenêtre principal de l'application
        FrmPrincipal = new frmPrincipal();
        FrmPrincipal.setVisible(true);
    }

La seule différence entre les deux codes est l'emplacement de ma déclaration de fenêtre.

verdy_p · Answer

Demande toi alors pourquoi l'appel de ***ton*** constructeur de fenêtre "new frmPrincipal()" modifie les propriétés système. Il y a fort à parier que c'est ***ton*** constructeur qui provoque ça en purgeant ou réinitialisant complètement ou filtrant ces propriétés -- qui ne disparaissent pas toutes seules par magie.


Encore une fois, impossible de savoir ce que fait ***ton*** constructeur, et la chaine d'évènements qui peut être déclenchée, d'autant que les composants de fenêtre peuvent avori de très nombreuses interactions et employer des tas de librairies diverses.


Note: ton code utilises System.getProperties pour obtenir une référence à la collections complète de propriétés; si tu peux le faire, ton constructeur de fenêtre peut le faire aussi; comme le résultat est une référence directe à l'objet Properties singleton instancé par la classe System, rien n'interdit ensuite de modifier le contenu de cette collection ainsi facilement référencée, ce que visiblement ton constructeur de fenêtre (et les méthodes qu'il emploie ou déclenche indirectement) ne se prive pas. Le code:
    Properties props = System.getProperties(); 
    String Location = System.getProperty("user.dir"); //Retourne le chemin absolu
est aussi équivalent à:
    Properties props = System.getProperties(); 
    String Location = props.getProperty("user.dir"); //Retourne le chemin absolu
Visiblement ton constructeur de fenêtre semble effectuer en interne (ou dans une des méthodes employées):
    Properties props = System.getProperties(); 
    props.setProperty("user.dir", null); // ou pire encore: props.clear();
Peut-être qu'il modifie une collection qu'il n'était pas sensée modifier. S'il y a bogue quelque part c'est dans ***ton*** code.

System.getProperty("user.dir") = NULL

5 réponses

Votre réponse

Discussions similaires