Répertoire actuel en Java en 2025 : 3 méthodes et pièges

Où suis-je ? Ou comment ne pas se perdre dans le système de fichiers d'une application Java

Chaque développeur Java s'est posé au moins une fois la question : « Mais où, exactement, mon code s'exécute-t-il ? » Apparemment, on lance le programme depuis l'IDE, tout fonctionne. Mais dès qu'on le déplace sur un serveur ou dans un conteneur Docker, les fichiers qui devaient se trouver à côté du fichier jar se retrouvent quelque part dans les profondeurs de /opt/app ou /tmp. Une situation familière ?

La question « How to get the current working directory in Java? » est l'une des plus populaires sur Stack Overflow. Et ce n'est pas sans raison : la réponse semble évidente, mais en pratique, elle cache de nombreux pièges. Dans cet article, nous analyserons les meilleures pratiques de 2025 : comment obtenir de manière fiable le current working directory, quand lui faire confiance, et quand il est préférable de chercher des alternatives.

Avertissement : l'article est écrit pour Java 17+ (LTS), mais les exemples sont compatibles avec Java 11 et versions ultérieures. Si vous êtes encore sur Java 8, mettez à jour d'urgence, mais le code fonctionnera aussi.

La méthode classique : System.getProperty("user.dir")

La méthode la plus simple et la plus largement utilisée consiste à accéder à la propriété système user.dir. C'est ce que vous verrez dans 90% des réponses sur Stack Overflow :

public class WorkingDirectoryExample {\n    public static void main(String[] args) {\n        String cwd = System.getProperty("user.dir");\n        System.out.println("Répertoire actuel : " + cwd);\n    }\n}

Qu'obtiendrez-vous en sortie ? Le chemin vers le dossier à partir duquel la JVM a été lancée. Si vous lancez depuis la racine du projet, ce sera /Users/you/projects/my-app. Si vous lancez depuis target/, ce sera target/.

Pourquoi ce n'est pas toujours fiable ?

Problème n°1 : Les IDE et les systèmes de build trompent. IntelliJ IDEA définit par défaut le working directory comme la racine du module. Maven — la racine du projet. Gradle — la racine du module. Mais cela peut être redéfini dans la configuration de lancement. Résultat : le code fonctionne en local, mais pas sur le serveur.

Problème n°2 : Les tests unitaires. Lors de l'exécution via JUnit ou TestNG, le working directory peut être la racine du projet, ou bien le dossier de build. Cela dépend des paramètres du runner.

Problème n°3 : Les applications web et les microservices. Dans les conteneurs (Tomcat, Jetty), le working directory est souvent égal à $CATALINA_HOME/bin ou /. Cela n'a rien à voir avec votre fichier WAR.

L'approche moderne : java.nio.file.Paths

Depuis Java 7, nous avons une méthode plus « java-esque » via l'API NIO.2 :

import java.nio.file.Paths;\n\npublic class NioWorkingDirectory {\n    public static void main(String[] args) {\n        String cwd = Paths.get("").toAbsolutePath().toString();\n        System.out.println("Répertoire actuel (NIO) : " + cwd);\n    }\n}

Que se passe-t-il ici ? Paths.get("") crée une référence vers un chemin vide, qui est interprété comme un chemin relatif vers le répertoire actuel. La méthode toAbsolutePath() le résout en chemin absolu. Le résultat est le même que user.dir, mais avec un typage plus strict.

Avantages :

\n
• Fonctionne avec des objets Path, pas avec des chaînes (moins d'erreurs avec les séparateurs)
\n
• Peut être utilisé directement dans les API modernes
\n
• Multi-plateforme (Windows vs Linux)
\n

Inconvénients : les mêmes — il s'agit toujours du working directory du processus.

Alternative : File("")

Pour ceux qui ne veulent pas passer à NIO (bien que ce soit dommage) :

import java.io.File;\n\npublic class FileWorkingDirectory {\n    public static void main(String[] args) {\n        String cwd = new File("").getAbsolutePath();\n        System.out.println("Répertoire actuel (File) : " + cwd);\n    }\n}

Exactement la même chose que Paths.get("").toAbsolutePa