fix: review and restructure the roadmap

Author: Bulletdev

02 - Configurando o Ambiente/2.2 - Maven e Gradle/readme.md

@@ -554,129 +554,11 @@ zipStorePath=wrapper/dists
 
 > **Regra prática:** em projeto legado, siga o que já existe. Em projeto novo, use Gradle com Kotlin DSL se a equipe topar a curva de aprendizado; caso contrário, Maven é sempre uma escolha segura.
 
+
 ---
 
 ## GraalVM Native Image
 
-O **GraalVM Native Image** compila sua aplicação Java para um **executável nativo** usando AOT (Ahead-of-Time compilation), eliminando a JVM em tempo de execução.
-
-### O que é compilação AOT
-
-Compilação tradicional Java:
-```
-Código .java → Bytecode .class → JVM interpreta/JIT compila → Execução
-```
-
-Compilação AOT com GraalVM:
-```
-Código .java + Análise estática de tudo → Executável nativo binário → Execução direta
-```
-
-**Resultado:** startup em ~50ms (vs ~3s com JVM), uso de memória 10x menor, binário único sem dependências externas — ideal para **serverless, containers, microsserviços**.
-
-### Configurar no pom.xml
-
-```xml
-<!-- Adicionar o perfil native -->
-<profiles>
-    <profile>
-        <id>native</id>
-        <build>
-            <plugins>
-                <plugin>
-                    <groupId>org.graalvm.buildtools</groupId>
-                    <artifactId>native-maven-plugin</artifactId>
-                    <version>0.10.3</version>
-                    <extensions>true</extensions>
-                    <executions>
-                        <execution>
-                            <id>build-native</id>
-                            <goals>
-                                <goal>compile-no-fork</goal>
-                            </goals>
-                            <phase>package</phase>
-                        </execution>
-                        <execution>
-                            <id>test-native</id>
-                            <goals>
-                                <goal>test</goal>
-                            </goals>
-                            <phase>test</phase>
-                        </execution>
-                    </executions>
-                    <configuration>
-                        <!-- Nome do executável gerado -->
-                        <imageName>sistema-financeiro</imageName>
-                        <!-- Argumentos para o compilador nativo -->
-                        <buildArgs>
-                            <buildArg>--no-fallback</buildArg>
-                            <buildArg>-H:+ReportExceptionStackTraces</buildArg>
-                            <!-- Otimização máxima (build mais lento, binário menor) -->
-                            <buildArg>-O3</buildArg>
-                        </buildArgs>
-                    </configuration>
-                </plugin>
-
-                <!-- Spring Boot 3+ tem suporte nativo integrado -->
-                <plugin>
-                    <groupId>org.springframework.boot</groupId>
-                    <artifactId>spring-boot-maven-plugin</artifactId>
-                    <configuration>
-                        <image>
-                            <!-- Gerar imagem Docker nativa com Buildpacks -->
-                            <name>minha-empresa/sistema-financeiro:native</name>
-                            <builder>paketobuildpacks/builder-jammy-tiny</builder>
-                            <env>
-                                <BP_NATIVE_IMAGE>true</BP_NATIVE_IMAGE>
-                            </env>
-                        </image>
-                    </configuration>
-                </plugin>
-            </plugins>
-        </build>
-    </profile>
-</profiles>
-```
-
-### Build nativo
-
-```bash
-# Compilar para executável nativo (requer GraalVM instalado)
-mvn -Pnative package
-
-# O executável estará em:
-ls -lh target/sistema-financeiro
-# -rwxr-xr-x  1 user  group  52M  sistema-financeiro
-
-# Executar — sem JVM, startup em ~50ms
-./target/sistema-financeiro
-
-# Gerar imagem Docker nativa (não precisa GraalVM local)
-mvn spring-boot:build-image -Pnative
-docker run --rm minha-empresa/sistema-financeiro:native
-```
-
-### Instalar GraalVM
-
-```bash
-# Via SDKMAN (recomendado)
-sdk install java 21.0.4-graal
-sdk use java 21.0.4-graal
-
-# Verificar
-java -version
-# java version "21.0.4" 2024-07-16 LTS
-# Java(TM) SE Runtime Environment GraalVM EE 21.0.4+8.1-LRE (build 21.0.4+8-jvmci-23.1-b41)
-
-# Instalar native-image (necessário para compilação AOT)
-gu install native-image
-```
-
-### Limitações do Native Image
-
-- **Reflexão precisa ser declarada:** código que usa `Class.forName()` ou frameworks que usam reflexão extensivamente (como Spring) precisam de hints
-- **Build demora muito:** um build nativo pode levar 5-15 minutos vs 30 segundos com JVM
-- **Sem hot reload:** não é possível modificar e recarregar código em runtime
-- **Spring Boot 3+ mitiga a maioria:** com AOT hints gerados automaticamente
+GraalVM Native Image usa AOT (Ahead-of-Time compilation) para transformar sua aplicação em um executável nativo, sem JVM em runtime. O resultado é startup em ~50ms, consumo de memória dramaticamente menor e um binário único — características valiosas para serverless e microsserviços com muitas instâncias.
 
-> **Quando usar:** lambdas, functions serverless, CLIs, microsserviços com muitas instâncias (para reduzir custo de memória em Kubernetes). Para aplicações monolíticas com tempo de startup irrelevante, a JVM ainda é mais vantajosa.
+Entender por que o Native Image existe e por que ele tem limitações específicas com reflexão requer compreender o que o ClassLoader faz, o ciclo de JIT compilation e por que um fat JAR do Spring Boot pode levar vários segundos para inicializar. Esse contexto está coberto no módulo 8.3 (Otimização de Performance e JVM), que inclui os detalhes completos de configuração, hints de reflexão, instalação do GraalVM e a decisão de quando o custo de build de 5-15 minutos compensa.

03 - Dominando o Java/3.1 - Recursos Modernos do Java 21 e 25/readme.md

@@ -584,131 +584,15 @@ mapa.forEach((_, valor) -> processar(valor));
 
 ---
 
-## Virtual Threads (Java 21)
-
-Virtual Threads são threads "leves" gerenciadas pela JVM, criadas em milhares sem o custo das threads de sistema operacional.
-
-**Problema que resolve:** escalabilidade de I/O bloqueante sem precisar de programação reativa complexa.
-
-### O problema que Virtual Threads resolvem
-
-```
-Thread de S.O. tradicional:
-- ~1MB de memória de stack
-- Custo alto de criação e troca de contexto
-- Servidor com 16GB de RAM: máximo ~16.000 threads simultâneas
-
-Virtual Thread:
-- ~few KB de memória
-- Gerenciada pela JVM sobre um pool de carrier threads
-- Servidor com 16GB de RAM: milhões de virtual threads simultâneas
-```
-
-### Como criar Virtual Threads
-
-```java
-// Forma 1: Thread.ofVirtual()
-Thread vt = Thread.ofVirtual()
-    .name("vt-processamento")
-    .start(() -> {
-        // Código que pode fazer I/O bloqueante com segurança
-        var resultado = repositorio.buscarDados(id);   // bloqueia, mas não desperdiça
-        processar(resultado);
-    });
-
-// Forma 2: ExecutorService com virtual threads (mais comum)
-try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
-    for (var pedido : listaDePedidos) {
-        executor.submit(() -> processarPedido(pedido));
-    }
-}   // aguarda todas terminarem ao fechar o try
-
-// Forma 3: com structured concurrency (Java 21+)
-try (var scope = new StructuredTaskScope.ShutdownOnFailure()) {
-    var futuroPagamento  = scope.fork(() -> verificarPagamento(pedidoId));
-    var futuroEstoque    = scope.fork(() -> verificarEstoque(pedidoId));
-    var futuroFraude     = scope.fork(() -> analisarFraude(pedidoId));
-
-    scope.join().throwIfFailed();   // aguarda todos e propaga erros
-
-    var pagamento = futuroPagamento.get();
-    var estoque   = futuroEstoque.get();
-    var fraude    = futuroFraude.get();
-
-    return new ResultadoVerificacao(pagamento, estoque, fraude);
-}
-```
 
-### Quando usar Virtual Threads
-
-```java
-// IDEAL: operações de I/O bloqueante
-// - Chamadas HTTP a APIs externas
-// - Consultas ao banco de dados
-// - Leitura/escrita de arquivos
-// - Chamadas a filas de mensagens (Kafka, RabbitMQ)
-
-@GetMapping("/pedido/{id}/detalhes")
-public PedidoDetalhes obterDetalhes(@PathVariable UUID id) {
-    // Com Virtual Threads no Spring Boot 3.2+, cada request já roda em uma virtual thread
-    // Não precisa de WebFlux/Reactive — código imperativo simples
-    var pedido      = pedidoRepo.findById(id).orElseThrow();    // I/O bloqueante — OK
-    var pagamento   = pagamentoClient.buscar(id);                // HTTP bloqueante — OK
-    var rastreio    = logisticaClient.buscar(id);                // HTTP bloqueante — OK
-
-    return new PedidoDetalhes(pedido, pagamento, rastreio);
-}
-```
-
-### Quando NÃO usar Virtual Threads
-
-```java
-// NÃO USAR 1: operações CPU-bound (não há benefício)
-// Virtual threads não ajudam quando o CPU está ocupado, não esperando I/O
-public BigDecimal calcularSimulacaoMonteCarlo(int iteracoes) {
-    // Isso vai no pool de threads tradicional (ForkJoinPool)
-    return IntStream.range(0, iteracoes)
-        .parallel()
-        .mapToDouble(i -> simular())
-        .average()
-        .orElse(0);
-}
-
-// NÃO USAR 2: synchronized com monitor (causa "pinning" da carrier thread)
-// PROBLEMÁTICO com virtual threads:
-public synchronized void processarComSynchronized() {
-    // A virtual thread "prega" (pins) a carrier thread durante todo o bloqueio
-    buscarDoBanco();  // I/O aqui bloqueia a carrier thread inteira — perde o benefício
-}
+## Virtual Threads (Java 21)
 
-// CORRETO: usar ReentrantLock em vez de synchronized quando há I/O interno
-private final ReentrantLock lock = new ReentrantLock();
+Virtual Threads são o mecanismo que permite escrever código I/O bloqueante com a escalabilidade de código reativo, sem a complexidade de Mono/Flux. Criadas em milhões com custo de memória de poucos kilobytes cada, elas mudam a relação entre concorrência e simplicidade de código.
 
-public void processarComLock() {
-    lock.lock();
-    try {
-        buscarDoBanco();  // Virtual thread pode ser suspensa aqui — OK
-    } finally {
-        lock.unlock();
-    }
-}
-```
+O funcionamento interno — carrier threads, mounting/unmounting, o problema de pinning com synchronized — está coberto no módulo 3.4, onde o tema é tratado junto com ExecutorService, race conditions e as demais ferramentas de concorrência. A configuração do Spring Boot para habilitar virtual threads por request também está lá.
 
-### Habilitando no Spring Boot 3.2+
+Para referência rápida: `spring.threads.virtual.enabled=true` em `application.properties` é suficiente no Spring Boot 3.2+.
 
-```java
-// application.properties
-// spring.threads.virtual.enabled=true
-
-// Ou via código
-@Bean
-public TomcatProtocolHandlerCustomizer<?> virtualThreadsCustomizer() {
-    return protocolHandler ->
-        protocolHandler.setExecutor(Executors.newVirtualThreadPerTaskExecutor());
-}
-```
-
----
 
 ## Resumo visual das features por versão
 

04 - Intermediário/4.2 - JSON com Jackson/readme.md

@@ -1,6 +1,6 @@
 # 4.2 — JSON com Jackson
 
-Jackson é a biblioteca de serialização/desserialização JSON mais usada no ecossistema Java. É a padrão do Spring Boot e suporta desde casos simples até cenários complexos com tipos genéricos, customizações e módulos de extensão.
+Jackson é a biblioteca que o Spring Boot usa para converter objetos Java em JSON e vice-versa. Na maioria dos projetos, ela funciona transparentemente — até o dia em que não funciona. `UnrecognizedPropertyException` quando o JSON de entrada tem um campo que seu DTO não mapeia. `InvalidDefinitionException` porque o `ObjectMapper` não sabe serializar `LocalDateTime` sem o `JavaTimeModule`. `MismatchedInputException` ao deserializar um array para um tipo genérico sem `TypeReference`. Este guia cobre o suficiente para você entender o que está acontecendo quando essas exceções aparecem, e como configurar o Jackson corretamente desde o início.
 
 ---
 

05 - Frameworks/5.3 - Spring Security/readme.md

@@ -64,6 +64,8 @@ Spring Security é o framework de segurança padrão para aplicações Java. Ele
 
 A partir do Spring Security 5.7+, não se usa mais `extends WebSecurityConfigurerAdapter`. Toda a configuração é feita via `SecurityFilterChain` bean.
 
+Vale notar: o `SecurityFilterChain` é uma aplicação direta do padrão Chain of Responsibility da GoF. Cada `Filter` na cadeia decide se processa a requisição e a passa adiante ou a intercepta. Quando você implementa `OncePerRequestFilter` para validar o JWT, está adicionando um elo concreto nessa cadeia. Esse padrão e sua estrutura formal estão documentados no módulo 7.1.
+
 ### `SecurityFilterChain`
 
 ```java