Compilar é bom. Mas ver a aplicação rodando com seus próprios olhos muda tudo.

🎯 Depois do build, o que falta?

No capítulo anterior, conseguimos algo significativo: compilar com sucesso o código-fonte do ProjectLibre. Foi um avanço importante para um projeto legado como esse, que não conta com uma documentação moderna nem com uma estrutura de build facilitada. Mas, por mais que o build tenha gerado artefatos válidos, o código ainda estava “parado” — não sabíamos se a aplicação realmente funcionava. Agora, nossa missão é clara: descobrir como rodar o software localmente, como se ele tivesse acabado de ser instalado por um usuário qualquer.

Para isso, precisamos encontrar o ponto de entrada da aplicação. Em outras palavras, precisamos entender onde e como o ProjectLibre começa a ser executado. E no universo Java, isso costuma girar em torno de um único método: o famoso main().

🔍 Todo programa Java começa no main()

Se você já teve qualquer contato com Java, provavelmente sabe que toda aplicação começa com um método main(), geralmente definido como public static void main(String[] args). Esse método é a porta de entrada da JVM (Java Virtual Machine) para o mundo da aplicação. Quando você roda um programa Java, é esse ponto que determina o que será executado primeiro, e a partir daí o fluxo do software se desenrola.

No caso do ProjectLibre, o desafio foi encontrar essa função dentro de uma base de código extensa e segmentada em múltiplos módulos. Felizmente, o IntelliJ ajuda muito nessa parte. Ao usar a busca por arquivos (atalho Shift + Shift), procurei por Main.java — e ali estava ele, dentro do módulo projectlibre_ui. Isso já era um bom sinal: se a classe Main está localizada na parte do projeto responsável pela interface gráfica, é bem provável que seja ela que dá início à execução da aplicação como um todo.

image.png

▶️ Rodando pela primeira vez

Ao abrir o arquivo Main.java no IntelliJ, logo no canto superior direito aparece o botão de execução com o texto “Run ‘Main.main()’”. Esse botão é a forma mais direta e segura de pedir para a IDE rodar o método principal da classe. Ao clicar nele, o IntelliJ cuida de todo o processo de compilação incremental e inicia a execução do projeto a partir desse ponto.

image.png

E foi aí que aconteceu: a aplicação finalmente abriu em minha máquina. Com o clique em um único botão, vi o ProjectLibre sendo executado diretamente do código-fonte compilado localmente. Um momento pequeno, mas simbólico — e muito importante. Agora tenho controle completo: posso explorar o fluxo do programa, depurar qualquer parte do código e, principalmente, começar a fazer alterações que serão refletidas imediatamente na aplicação em funcionamento.

image.png

⚙️ Criando uma configuração de execução personalizada

Mesmo que seja possível rodar a aplicação diretamente pela classe Main.java, essa abordagem exige abrir o arquivo e clicar manualmente toda vez. Para facilitar o processo de desenvolvimento contínuo, o IntelliJ permite criar uma Run Configuration personalizada, que associa um nome à forma correta de iniciar o projeto.

O processo é simples e vale muito a pena. Basta clicar com o botão direito sobre o arquivo Main.java, escolher a opção More Run/Debug e depois ir em Modify Run Configuration…. Ali, você poderá confirmar os parâmetros padrão, dar um nome à configuração e salvar. A partir disso, sempre que quiser rodar a aplicação, basta usar esse atalho direto — sem a necessidade de navegar até o arquivo novamente.

Essa prática é especialmente útil para projetos com múltiplos pontos de entrada ou vários módulos que possam ser executados de forma independente. Como aqui estamos trabalhando com um sistema modular, manter essa clareza desde o início evita confusão mais adiante.

image.png

🧪 O próximo desafio: entender a interface gráfica

Agora que conseguimos executar o ProjectLibre localmente, temos as condições ideais para começar a investigar o funcionamento interno da aplicação. O primeiro alvo dessa investigação será o módulo de interface gráfica. Ele é responsável por todas as telas, menus, formulários e interações do usuário — e, ao mesmo tempo, é a parte que mais denuncia o peso do tempo nesse projeto.