Agora que já usamos a ferramenta, é hora de levantar o capô e entender como ela funciona por dentro.
Com o repositório clonado localmente, meu primeiro passo foi abrir o projeto no Visual Studio Code para fazer uma leitura geral da estrutura. Essa etapa é fundamental quando se trata de um código legado: antes de alterar qualquer coisa, é essencial observar, reconhecer padrões e entender o terreno. A estrutura inicial de diretórios já oferece vários indícios de como o projeto foi organizado — e, em alguns casos, de como ele evoluiu (ou não) com o tempo.
projectlibre-code
├── .idea/
└── projectlibre_build/
└── projectlibre_contrib/
└── projectlibre_core/
└── projectlibre_exchange/
└── projectlibre_reports/
└── projectlibre_ui/
└── .gitignore
└── .project
└── projectlibre_desktop.iml
Logo vieram algumas pistas importantes. A presença de centenas de arquivos .java deixou claro que se trata de um projeto Java “raiz”. Os diretórios prefixados por projectlibre_ sugerem módulos separados por responsabilidade — núcleo de regras de negócio (core), interface gráfica (ui), camada de troca de dados (exchange), gerador de relatórios (reports) e assim por diante. Essa organização modular ajuda tanto no entendimento como na manutenção do projeto.
Além disso, encontrei arquivos que indicam quais ferramentas foram utilizadas durante o desenvolvimento. O diretório .idea/ aponta para o uso do IntelliJ IDEA, uma das IDEs mais populares para projetos Java. Já os arquivos .project e projectlibre_desktop.iml são metadados de projeto, respectivamente das IDEs Eclipse e IntelliJ. Isso mostra que o projeto provavelmente passou por diferentes ambientes ao longo do tempo — ou pelo menos tentou manter compatibilidade com ambos
No artigo anterior, baixamos e testamos o executável do ProjectLibre, ou seja, o código já compilado e empacotado em um formato pronto para uso. Agora, com o código-fonte em mãos, o objetivo é exatamente o oposto: compilar manualmente, inspecionar cada parte e criar condições para debugar e modificar o sistema.
Decidi usar o próprio IntelliJ Community, já que o repositório possui a estrutura nativa dessa IDE. A vantagem disso é evitar perder tempo configurando tudo do zero — e, claro, aproveitar os mesmos caminhos que os desenvolvedores originais provavelmente seguiram.
Importei o projeto no IntelliJ e fui direto na opção Build > Build Project. Em projetos Java, o processo de build consiste em compilar os arquivos .java para bytecode, gerenciar dependências, empacotar os artefatos e, se configurado, executar testes. Essa é a etapa onde geralmente surgem os primeiros desafios em projetos legados — e aqui não foi diferente.
⚡ Em Java, buildar significa rodar uma sequência de tarefas que compila os
.javaem bytecode, resolve dependências, gera artefatos (JARs ou executáveis) e, opcionalmente, executa testes automatizados.
Logo recebi a seguinte mensagem de erro: "No JDK configured for project". Isso é esperado em projetos Java recém-importados, especialmente quando o JDK (Java Development Kit) não está definido na IDE. O JDK é um pacote essencial que contém o compilador Java, as bibliotecas padrão e ferramentas necessárias para transformar o código-fonte em um programa executável.
Java Development Kit (JDK)
É o pacote que contém compilador, bibliotecas padrão e ferramentas de depuração. Sem um JDK escolhido, a IDE não sabe contra qual linguagem e API compilar o projeto.
Antes de configurar o JDK manualmente, é necessário descobrir qual versão foi usada no desenvolvimento original. Usar uma versão incompatível pode gerar erros de compilação, métodos depreciados ou até falhas de execução. Vasculhando a pasta .idea, encontrei o arquivo misc.xml com o seguinte trecho:
<?xml version="1.0" encoding="UTF-8"?>
<project version="4">
<component name="ProjectRootManager" version="2" languageLevel="JDK_21" default="true" project-jdk-name="homebrew-21" project-jdk-type="JavaSDK">
<output url="file://$PROJECT_DIR$/classes" />
</component>
</project>