Depois de conseguir rodar o ProjectLibre localmente, uma coisa começou a me incomodar cada vez mais: a quantidade de warnings no código. A IDE IntelliJ faz um ótimo trabalho destacando possíveis problemas — desde imports não utilizados até uso de métodos obsoletos ou padrões de codificação ultrapassados. A cada arquivo aberto, lá estavam eles: dezenas de sublinhados amarelos me lembrando que o código poderia (e deveria) estar mais limpo.
E por mais que warnings não impeçam o software de funcionar, eles são sinais importantes de que há espaço para melhorias. Em um projeto legado, ignorar esses alertas é como morar em uma casa antiga e não se importar com os fios expostos. Pode funcionar hoje, mas vai dar trabalho amanhã.
Minha meta nesse momento não é refatorar completamente o código nem modernizar toda a base de uma vez (isso ainda vai acontecer…). O foco é mais prático e direto: eliminar o máximo possível de warnings que o IntelliJ aponta, sempre garantindo que a aplicação continue compilando e funcionando como antes.
Na maioria dos casos, os próprios avisos vêm com sugestões de correção da IDE. Algumas dessas mudanças são simples — como remover variáveis não utilizadas, usar tipos genéricos corretamente ou aplicar anotações padrão —, e outras exigem um pouco mais de cuidado, especialmente quando envolvem bibliotecas antigas ou comportamentos que podem mudar com refatorações automáticas.
Como parte desse processo, disponibilizei o código-fonte atualizado no GitHub. O repositório inclui uma documentação inicial, com instruções simples sobre como:
Além disso, criei uma lista de issues com warnings mapeados. Cada item descreve o local do código afetado, qual é o warning exibido e, sempre que possível, sugestões de como resolvê-lo. O objetivo é que qualquer pessoa possa entrar no projeto, escolher uma issue, resolver e contribuir.
👉 Repositório no GitHub: https://github.com/igorcarvalhh/freeflow
👉 Lista de warnings abertos como issues: https://github.com/igorcarvalhh/freeflow/issues
Se você está aprendendo Java, quer praticar contribuindo com projetos reais ou tem interesse em projetos open source, esse é um ótimo ponto de entrada. Cada warning resolvido ajuda a melhorar a legibilidade, manutenção e estabilidade do projeto — além de facilitar futuras modernizações que planejamos fazer.
Você pode contribuir de várias formas: