Pitch: Construí um Framework Java do Zero para provar que a base importa · ronerjr

A Engenharia por trás de um Framework Java: Por que construí o Bedrock do zero?

Se você é um engenheiro de software experiente, o ecossistema do Spring Boot (ou Quarkus/Micronaut) é o seu maior aliado. A "mágica" da autoconfiguração poupa semanas de trabalho boilerplate, conectando bancos de dados, filas e servidores web silenciosamente.

Porém, essa mesma "mágica" criou uma lacuna perigosa na formação das novas gerações de desenvolvedores.

Ao observar a comunidade, noto que a pressão do mercado faz com que muitos pulem os fundamentos da JVM. O resultado é a síndrome do "Colador de Anotações". O desenvolvedor sabe que @Autowired injeta uma classe, mas não tem a menor ideia de como um contêiner de Inversão de Controle (IoC) gerencia o ciclo de vida dos objetos em memória. Quando o Spring devolve um StackTrace de 300 linhas do Tomcat, bate o desespero.

Para curar essa dor (e provar que a biblioteca padrão do Java 21 é incrivelmente poderosa por si só), eu criei o Bedrock Java — um framework web construído do absoluto zero, com Zero Dependências Externas (sem Tomcat, Netty, Jackson ou Hibernate).

E para testar os limites dessa arquitetura, construí o BedrockLink, um encurtador de URLs de altíssima performance.

Neste artigo, convido você a abrir o capô do Bedrock. Vamos analisar 4 decisões profundas de arquitetura que estruturam o framework.

1. Desmistificando o IoC: Injeção de Dependências Imutável

No ecossistema Java moderno, a injeção via atributos (@Autowired em campos privados) é desencorajada por dificultar os testes unitários e quebrar o encapsulamento. O Bedrock foi desenhado para forçar as melhores práticas: ele suporta apenas Injeção por Construtor.

Mas como isso funciona sem o Spring? No núcleo do Bedrock, nós criamos um BedrockContainer baseado em teoria de grafos e Reflection.

Quando a aplicação sobe, você mapeia os controladores. O motor do Bedrock faz o seguinte:

Lê o construtor da classe alvo.
Descobre de quais serviços ela depende.
Se o serviço ainda não existe na memória, ele desce na árvore (recursão) e tenta instanciar a dependência primeiro.

// Exemplo de como a Injeção acontece organicamente no BedrockLink:
public class LinkController {
    private final LinkService linkService;

    // O BedrockContainer descobre este construtor, 
    // instancia o LinkService (injetando o Repository nele) e passa para cá!
    public LinkController(LinkService linkService) {
        this.linkService = linkService;
    }
}

O maior ganho arquitetural? Se você criar uma Dependência Circular (Classe A depende de B, que depende de A), o Spring clássico costumava estourar a memória em tempo de execução. O motor do Bedrock intercepta o ciclo no momento do boot e lança uma exceção customizada, blindando a arquitetura logo na largada.

2. O Poder Bruto das Virtual Threads (Project Loom)

O Bedrock não utiliza servidores web massivos como o Tomcat. Ele se apoia no com.sun.net.httpserver.HttpServer, que já vem embutido na JVM.

O grande diferencial do Java 21 é o Project Loom. Antigamente, servidores bloqueavam uma Thread inteira do Sistema Operacional para cada requisição HTTP (o que exigia muito processador e RAM). No Bedrock, o servidor é mapeado diretamente para as Virtual Threads.

// O coração do servidor no BedrockApp.java
HttpServer server = HttpServer.create(new InetSocketAddress(port), 0);
// Aqui está a mágica da escalabilidade infinita do Java 21:
server.setExecutor(Executors.newVirtualThreadPerTaskExecutor());
server.start();

Para provar a eficiência disso em um cenário single-node, o projeto BedrockLink não usa bancos de dados externos. Ele armazena as URLs em um ConcurrentHashMap em memória.
Graças às Virtual Threads, ele é capaz de segurar dezenas de milhares de requisições concorrentes consumindo uma fração minúscula de memória, sem sofrer com gargalos clássicos de I/O de rede.

3. Abstração Elegante de I/O (O Padrão Context)

Lidar com o HttpExchange cru da JVM exige ler InputStreams, gerenciar byte arrays e calcular tamanhos de cabeçalho na mão. É brutal.

Para resolver isso, criamos o objeto de abstração Context (muito inspirado na fluidez do Express.js e do FastAPI). O desenvolvedor interage apenas com uma API limpa, enquanto o framework faz o trabalho sujo de I/O.

// Roteamento fluido e tipado no Bedrock
@BedrockPost("/api/links/create")
public void createLink(Context ctx) {
    // 1. Extração limpa do Body em String
    String url = ctx.body(); 
    
    // 2. Regra de negócio
    String hash = linkService.shorten(url); 
    
    // 3. Resposta com JSON nativo (Serializador criado com Reflection)
    ctx.created(Map.of("short_url", "http://localhost:8080/" + hash));
}

Isso une o melhor dos dois mundos: a agilidade de um framework em linguagem interpretada com a robustez impenetrável da tipagem estática do Java.

4. A Arquitetura de Pipeline (Middlewares)

Um framework maduro precisa de separação de responsabilidades. Autenticação e CORS não devem poluir a regra de negócio do Controller.

Implementamos uma arquitetura de Interceptadores. Antes da requisição tocar no Controller, ela atravessa um Pipeline. Veja como protegemos as rotas do encurtador usando um Middleware simples:

// ApiKeyMiddleware.java
public class ApiKeyMiddleware implements Middleware {
    @Override
    public boolean handle(Context ctx) {
        if (ctx.path().startsWith("/api/") && !ctx.header("x-api-key").equals("sua-chave-secreta")) {
            ctx.status(401).send("Acesso Negado.");
            return false; // Interrompe o fluxo (Short-circuit)
        }
        return true; // Libera o fluxo para o Controller
    }
}

Conclusão: Por que você deve abrir a caixa preta?

O mercado de tecnologia não busca mais "decoradores de frameworks". As empresas buscam engenheiros que entendam a física por trás do motor.

Estudar o Bedrock Java não é sobre abandonar o Spring Boot. Pelo contrário: é sobre entender a genialidade do Spring Boot recriando os mesmos padrões arquiteturais do zero, com as próprias mãos.

🔗 O código-fonte de ambos os projetos é Open-Source (e o framework já está disponível publicamente no Maven Central).

Convido você a clonar os repositórios, ler o código e subir os projetos na sua máquina:

O Framework (Bedrock Java): https://github.com/ronerjr/bedrock-framework
O Showcase (Encurtador BedrockLink): https://github.com/ronerjr/encurtador-links-bedrock

Agora, deixo uma pergunta para os colegas seniores e juniores da rede: Na sua opinião, qual é o conceito base da JVM (ou arquitetura) que os novatos mais têm dificuldade de entender hoje em dia?

Deixe nos comentários! 👇

#Java #SpringBoot #EngenhariaDeSoftware #Backend #OpenSource #Java21 #VirtualThreads #ProjectLoom #ArquiteturaDeSoftware