Diretório atual em Java em 2025: 3 maneiras e armadilhas

Onde estou? Ou como não se perder no sistema de arquivos de uma aplicação Java

Todo desenvolvedor Java já se perguntou pelo menos uma vez na vida: "Onde, afinal, meu código está sendo executado?" Você inicia o programa pela IDE, tudo funciona. Mas basta movê-lo para um servidor ou container Docker — e os arquivos que deveriam estar ao lado do arquivo jar acabam em algum lugar nos confins de /opt/app ou /tmp. Situação familiar?

A pergunta "How to get the current working directory in Java?" é uma das mais populares no Stack Overflow. E não é à toa: a resposta parece óbvia, mas na prática esconde várias armadilhas. Neste artigo, vamos abordar as melhores práticas de 2025: como obter o current working directory de forma confiável, quando confiar nele e quando é melhor buscar alternativas.

Aviso: o artigo foi escrito para Java 17+ (LTS), mas os exemplos são compatíveis com Java 11 e versões posteriores. Se você ainda está no Java 8 — atualize-se urgentemente, mas o código também funcionará.

Método clássico: System.getProperty("user.dir")

O método mais simples e amplamente utilizado é acessar a propriedade do sistema user.dir. É o que você verá em 90% das respostas no Stack Overflow:

public class WorkingDirectoryExample {\n    public static void main(String[] args) {\n        String cwd = System.getProperty("user.dir");\n        System.out.println("Diretório atual: " + cwd);\n    }\n}

O que você obterá como saída? O caminho para a pasta a partir da qual a JVM foi iniciada. Se você iniciar a partir da raiz do projeto, será /Users/you/projects/my-app. Se iniciar a partir de target/, será target/.

Por que isso nem sempre é confiável?

Problema nº1: IDEs e sistemas de build enganam. O IntelliJ IDEA, por padrão, define o working directory como a raiz do módulo. O Maven — a raiz do projeto. O Gradle — a raiz do módulo. Mas isso pode ser alterado na configuração de execução. Como resultado, o código funciona na máquina local, mas no servidor — não.

Problema nº2: Unit-tests. Ao executar via JUnit ou TestNG, o working directory pode ser a raiz do projeto ou a pasta de build. Depende das configurações do runner.

Problema nº3: Aplicações web e microsserviços. Em containers (Tomcat, Jetty), o working directory geralmente é $CATALINA_HOME/bin ou /. Isso não tem nenhuma relação com seu arquivo WAR.

Abordagem moderna: java.nio.file.Paths

A partir do Java 7, temos uma maneira mais "Java" — através da 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("Diretório atual (NIO): " + cwd);\n    }\n}

O que acontece aqui? Paths.get("") cria uma referência a um caminho vazio, que é interpretado como um caminho relativo para o diretório atual. O método toAbsolutePath() o resolve para um caminho absoluto. O resultado é o mesmo user.dir, mas com tipagem mais forte.

Vantagens:

\n
• Trabalha com objetos Path, não com strings (menos erros com separadores)
\n
• Pode ser usado diretamente em APIs modernas
\n
• Multiplataforma (Windows vs Linux)
\n

Desvantagens: as mesmas — ainda é o working directory do processo.

Alternativa: File("")

Para quem não quer migrar para o NIO (embora devesse):

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("Diretório atual (File): " + cwd);\n    }\n}

Exatamente a mesma coisa que Paths.get("").toAbsolutePa