"La evolución del software no ocurre de manera abrupta, sino como una serie de refinamientos deliberados que nos llevan a escribir código más expresivo, predecible y mantenible." — Venkat Subramaniam

Durante casi dos décadas, Spring ha sido sinónimo de productividad y elegancia en el desarrollo Java. Desde la eliminación del XML en favor de anotaciones hasta la simplificación del arranque con Spring Boot, su filosofía siempre ha sido clara: reducir la fricción del desarrollo sin comprometer la potencia.

Las próximas versiones de Spring Boot 4 y Spring Framework 7 no representan simplemente actualizaciones incrementales, encarnan un cambio fundamental hacia el desarrollo de aplicaciones empresariales cloud-native, modulares y resilientes. Estos lanzamientos abordan puntos críticos que han afligido a los desarrolladores Java durante años: la complejidad de evolución de APIs, la resiliencia de servicios, las brechas de observabilidad y las limitaciones de rendimiento en tiempo de ejecución.

Como arquitectos empresariales y desarrolladores senior, debemos comprender que estos no son simplemente adiciones de características, sino inversiones estratégicas en mantenibilidad a largo plazo y excelencia operacional.

---

1. La Motivación Detrás del Cambio: Comprendiendo el Espacio del Problema

El desarrollo moderno exige velocidad, escalabilidad y simplicidad. Las aplicaciones distribuidas requieren herramientas que permitan pensar en alto nivel, sin perder control sobre los detalles. Spring Boot 4 y Spring Framework 7 representan la convergencia de tres principios fundamentales:

El Dilema de la Evolución de APIs

Las aplicaciones empresariales raramente existen en aislamiento. Sirven a múltiples clientes—frontends web, aplicaciones móviles, integraciones de terceros, cada uno con diferentes requerimientos de ciclo de vida. El desafío no es construir APIs; es evolucionarlas sin romper contratos existentes.

Consideremos una API de servicios financieros que sirve tanto a una aplicación de escritorio legacy (actualizada anualmente) como a una app móvil moderna (actualizada mensualmente). Los enfoques tradicionales nos fuerzan a decisiones incómodas:

1. Proliferación de versiones: Crear endpoints separados para cada versión
2. Restricciones de compatibilidad: Limitar la innovación para mantener compatibilidad
3. Acumulación de deuda técnica: Mantener múltiples rutas de código indefinidamente

La Brecha de Resiliencia

Los sistemas distribuidos modernos fallan regularmente e impredeciblemente. Las particiones de red, timeouts de servicios y fallos en cascada no son excepciones, son la norma. Sin embargo, la mayoría de aplicaciones empresariales manejan estos escenarios como pensamientos posteriores, frecuentemente resultando en:

• Fallos en cascada a través de límites de servicios
• Pobre experiencia de usuario durante fallos transitorios
• Sobrecarga operacional en recuperación de fallos
• Dificultad en diagnóstico de patrones de fallo

El Desafío de Observabilidad

La depuración en producción permanece como una de las actividades más consumidoras de tiempo en el desarrollo empresarial. Sin observabilidad apropiada, los equipos gastan horas recreando problemas, analizando logs y realizando análisis forenses. El costo de pobre observabilidad se agrava con la complejidad de aplicación.

Como diría Venkat: "No se trata de escribir menos código, sino de escribir código que comunique más con menos palabras".

---

2. Fundamentos Renovados: La Base Tecnológica

Java Moderno Como Plataforma

Spring Boot 4 exige Java 17 como mínimo y recomienda fuertemente Java 21 o 25, aprovechando características que redefinen la concurrencia y la simplicidad del lenguaje:

• Virtual Threads (Project Loom): Manejo de miles de tareas concurrentes con costo mínimo de memoria
• Pattern Matching y Records: Claridad y reducción de verbosidad del código
• Mejoras en Garbage Collector: Optimizaciones significativas en rendimiento

Estas características no son meramente mejoras de rendimiento, habilitan nuevos patrones arquitecturales que simplifican el desarrollo de aplicaciones altamente concurrentes.

Jakarta EE 11: El Fin de javax.*

La migración a Jakarta EE 11 representa una decisión estratégica: el futuro del stack empresarial Java ya no está en javax.*, sino en jakarta.*. Spring Framework 7 adopta este cambio completamente, actualizando componentes críticos:

Componente	Versión
Servlet API	6.1
JPA (Hibernate)	3.2 (v7.0)
Bean Validation	3.1
Dependency Injection	Jakarta

Esta transición no es opcional, es el camino hacia adelante para todo el ecosistema Java empresarial.

Kotlin 2.2 y Programación Funcional

El soporte oficial para Kotlin 2.2+ refuerza la interoperabilidad. Las corutinas ahora fluyen de manera natural dentro de las APIs reactivas, permitiendo escribir código asincrónico más legible y determinista. Spring Framework 7 aprovecha las mejoras de null-safety de Kotlin para proporcionar contratos más seguros.

---

3. Spring Boot 4: Evolución Arquitectural

Optimización de Imagen Nativa: Más Allá del Rendimiento

La integración mejorada de GraalVM 24 en Spring Boot 4 aborda la economía fundamental de la nube. El procesamiento AOT (Ahead-of-Time) mejorado significa construcciones más rápidas y menor huella de memoria en arranque:

// Traditional JVM deployment
// Startup time: 45-60 seconds
// Memory footprint: 512MB baseline
// Cold start penalty: Significant

// Native image deployment
// Startup time: 50-100 milliseconds  
// Memory footprint: 32-64MB baseline
// Cold start penalty: Negligible

Esto no se trata meramente de tiempos de arranque más rápidos, se trata de habilitar nuevos patrones arquitecturales:

• Diseño serverless-first: Funciones que arrancan lo suficientemente rápido para invocación síncrona
• Escalado elástico: Instancias que pueden escalar hasta cero sin penalidad operacional
• Despliegue en edge: Servicios ligeros que pueden ejecutarse en ambientes con recursos limitados

Observabilidad Integrada: Micrometer 2 y OpenTelemetry

La integración de Micrometer 2 con OpenTelemetry ofrece una experiencia unificada para métricas, trazas y logs. Las aplicaciones cloud-native dependen de buena observabilidad, y Spring Boot 4 hace que traces, logs y métricas trabajen juntos sin configuración adicional:

management:
  tracing:
    enabled: true
    sampling.probability: 1.0
  metrics.export.prometheus.enabled: true

Este enfoque proporciona insights accionables para:

• Líneas base de rendimiento: Establecer métricas de cumplimiento de SLA
• Patrones de uso: Comprender utilización de características
• Planificación de capacidad: Predecir requerimientos de escalado
• Detección de anomalías: Identificar degradación de rendimiento

Arquitectura Modular: Precisión de Dependencias

La modularización interna de Spring Boot 4 refleja una comprensión madura de la gestión de dependencias empresariales. Los starters y auto-configuraciones ahora se distribuyen en módulos más pequeños y precisos, reduciendo la sobrecarga en:

• Optimización de construcción: Compilación más rápida y reducción del tamaño de artefactos
• Procesamiento AOT: No necesita lidiar con hints y metadata innecesarios
• Gestión de dependencias: Integraciones opcionales en módulos separados
• Mantenibilidad mejorada: Los módulos mapean más directamente a características

<!-- Previous approach: Monolithic starters -->
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-jpa</artifactId>
</dependency>

<!-- New approach: Modular architecture (internal) -->
<!-- Developers still use the same starter, -->
<!-- but internally it's split into focused modules -->

@ConfigurationPropertiesSource: Metadatos Mejorados

La nueva anotación @ConfigurationPropertiesSource mejora la generación de metadatos para proyectos modulares. Actúa como un hint para el procesador durante build time, garantizando que las propiedades estén documentadas completamente incluso cuando el código fuente se divide en varios módulos.

---

4. Spring Framework 7: Evolución de Filosofía de Diseño

API Versioning: Ciudadano de Primera Clase

Spring 7 introduce soporte nativo para versionado de APIs REST, eliminando la necesidad de soluciones personalizadas. El soporte nativo de versionado de API aborda un requerimiento empresarial fundamental—evolución de contratos de API sin cambios que rompan compatibilidad:

@RestController
@RequestMapping("/api/accounts")
public class AccountController {
    
    @RequestMapping(value = "/{id}", version = "1")
    public AccountSummary getAccountSummaryV1(@PathVariable String id) {
        return accountService.getBasicSummary(id);
    }
    
    @RequestMapping(value = "/{id}", version = "2") 
    public EnhancedAccountSummary getAccountSummaryV2(@PathVariable String id) {
        return accountService.getEnhancedSummary(id);
    }
}

Las estrategias de mapeo disponibles incluyen:

Estrategia	Ejemplo
Path-based	/api/v1/accounts vs /api/v2/accounts
Query parameter	/accounts?version=1 vs /accounts?version=2
Request header	X-API-Version: 1 vs X-API-Version: 2
Media type	Accept: application/vnd.api.v1+json

Este enfoque proporciona:

1. Responsabilidad única: Cada método maneja una versión del contrato
2. Ruta de evolución clara: La progresión de versiones es explícita y trazable
3. Enrutamiento flexible: Múltiples estrategias soportadas nativamente
4. Estrategia de deprecación: Soporte integrado para gestión de ciclo de vida de versiones

Integración Declarativa de Servicios: @HttpServiceClient

Inspirado en Feign pero más liviano y completamente integrado, la anotación @HttpServiceClient transforma la integración de servicios externos de programación imperativa a declarativa:

@HttpServiceClient("payment-service")
public interface PaymentClient {
    
    @PostExchange("/payments")
    @Retryable(maxAttempts = 3, backoff = @Backoff(delay = 1000, multiplier = 2))
    @ConcurrencyLimit(value = 10, timeout = Duration.ofSeconds(5))
    PaymentResponse processPayment(PaymentRequest request);
    
    @GetExchange("/payments/{id}/status")
    PaymentStatus getPaymentStatus(@PathVariable String id);
}

Este enfoque declarativo produce múltiples beneficios:

• Reducción de boilerplate: Elimina configuración repetitiva de cliente HTTP
• Resiliencia integrada: Patrones de retry y circuit breaker son declarativos
• Testabilidad: Fácil de mockear y verificar interacciones de servicios
• Externalización de configuración: Endpoints de servicios y políticas son configurables

Resiliencia como Preocupación Transversal

El concepto de resiliencia deja de ser un extra y pasa a ser parte del core. La integración de patrones de resiliencia directamente en el framework representa una comprensión madura de sistemas distribuidos. Las nuevas anotaciones @Retryable, @ConcurrencyLimit y @EnableResilientMethods permiten manejar fallos y control de concurrencia de manera declarativa:

@Service
@EnableResilientMethods
public class OrderProcessingService {
    
    @Retryable(
        value = {TransientServiceException.class},
        maxAttempts = 3,
        backoff = @Backoff(delay = 1000, multiplier = 1.5)
    )
    @ConcurrencyLimit(maxConcurrentCalls = 20)
    public OrderResult processOrder(OrderRequest request) {
        return externalOrderService.process(request);
    }
    
    @Recover
    public OrderResult recoverFromFailure(TransientServiceException ex, OrderRequest request) {
        return orderFallbackService.processOffline(request);
    }
}

Este enfoque asegura que la resiliencia no sea una idea posterior sino una consideración fundamental de diseño. Esto simplifica enormemente la adición de patrones de resiliencia sin necesitar bibliotecas adicionales como Resilience4j, aunque todavía se integran perfectamente.

BeanRegistrar: Registro Programático Avanzado

La interfaz BeanRegistrar simplifica el registro programático de beans con mayor flexibilidad, ideal para escenarios avanzados donde múltiples beans necesitan ser registrados dinámicamente:

@Configuration(proxyBeanMethods = false)
public class DynamicBeanConfig implements BeanRegistrar {
    
    @Override
    public void registerBeans(BeanDefinitionRegistry registry) {
        registry.registerBeanDefinition("auditService", 
            new RootBeanDefinition(AuditService.class));
    }
}

Esto permite registrar beans basándose en condiciones de runtime o configuración externa, haciendo la aplicación más dinámica y modular.

Null Safety con JSpecify

Las anotaciones de nulabilidad han estado dispersas en el ecosistema Java (@Nonnull, @Nullable, @NotNull, etc.). Con Spring Framework 7, el equipo adopta JSpecify como el estándar, mejorando el tooling de IDE y la interoperabilidad con Kotlin:

@Component
public class UserService {
    
    public @NonNull String getUserName(@Nullable String id) {
        if (id == null) {
            return "Unknown";
        }
        return "User " + id;
    }
}

Esto reduce el riesgo de NullPointerExceptions en bases de código más grandes y fortalece los contratos entre módulos.

RestTestClient: Testing Simplificado

El nuevo RestTestClient hace más fácil probar endpoints REST de manera similar a WebTestClient, pero sin traer infraestructura reactiva:

@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)
class AccountApiIntegrationTest {
    
    RestTestClient client;
    
    @BeforeEach
    void setUp(WebApplicationContext context) {
        client = RestTestClient.bindToApplicationContext(context).build();
    }
    
    @Test
    void shouldFetchAccountDetails() {
        client.get()
            .uri("/api/v1/accounts/123")
            .exchange()
            .expectStatus().isOk()
            .expectHeader().contentTypeCompatibleWith(MediaType.APPLICATION_JSON)
            .expectBody(Account.class)
            .consumeWith(account -> 
                assertThat(account.getResponseBody().getId()).isEqualTo("123")
            );
    }
}

JmsClient y Mejoras en JdbcClient

El nuevo JmsClient proporciona una API moderna para trabajar con JMS (Java Message Service), mientras que JdbcClient ha sido mejorado para operaciones de base de datos más fáciles y flexibles:

// JmsClient
JmsClient jmsClient = JmsClient.create(connectionFactory);
jmsClient.send("orderQueue", "New Order: #12345");

// JdbcClient enhancements
JdbcClient jdbcClient = JdbcClient.create(dataSource);
List<User> users = jdbcClient
    .sql("SELECT * FROM users WHERE status = :status")
    .param("status", "ACTIVE")
    .query(User.class)
    .list();

---

5. Consideraciones de Rendimiento: Más Allá de Benchmarks

Eficiencia de Memoria en Producción

La compilación de imagen nativa cambia fundamentalmente los patrones de utilización de memoria:

# Traditional JVM deployment
$ docker stats
CONTAINER CPU % MEM USAGE / LIMIT    MEM %
app       2.5%  512MiB / 1GiB        50%

# Native image deployment
$ docker stats  
CONTAINER CPU % MEM USAGE / LIMIT    MEM %
app       1.2%  48MiB / 1GiB         4.8%

Esta eficiencia permite:

• Mayor densidad de contenedores: Más servicios por nodo
• Reducción de costos de infraestructura: Menores requerimientos de memoria
• Escalabilidad mejorada: Provisión más rápida de instancias

Optimización de Arranque y AOT

Las mejoras de procesamiento AOT (Ahead-of-Time) producen beneficios medibles:

• Reducción tiempo de construcción: 40-60% compilación más rápida
• Mejora tiempo de arranque: 80-90% reducción en arranque frío
• Eliminación de reflexión: Resolución en tiempo de compilación de llamadas de reflexión
• Spring Data AOT Repositories: Los métodos de query se convierten en código fuente compilado

---

6. Observabilidad y Trazado Distribuido

Desarrollo Dirigido por Métricas

El stack mejorado de observabilidad de Spring Boot 4 habilita toma de decisiones dirigida por métricas:

@RestController
public class ProductController {
    
    private final MeterRegistry meterRegistry;
    
    @GetMapping("/products/{id}")
    @Timed(name = "product.lookup", description = "Product lookup time")
    public Product getProduct(@PathVariable String id) {
        
        Counter.builder("product.requests")
            .tag("product.type", determineProductType(id))
            .register(meterRegistry)
            .increment();
        
        return productService.findProduct(id);
    }
}

Trazado End-to-End con OpenTelemetry

La integración OpenTelemetry habilita trazado de peticiones completo a través de servicios distribuidos:

@Service
public class OrderService {
    
    @TraceAsync
    public CompletableFuture<Order> processOrderAsync(OrderRequest request) {
        Span span = tracer.nextSpan()
            .name("order.processing")
            .tag("order.type", request.getType())
            .start();
        
        try (Tracer.SpanInScope ws = tracer.withSpanInScope(span)) {
            return CompletableFuture.supplyAsync(() -> {
                return processOrder(request);
            });
        } finally {
            span.end();
        }
    }
}

---

7. Limpieza y Deprecaciones: Modernización del Ecosistema

Con la modernización vienen la limpieza. Spring 7 elimina dependencias obsoletas y estándares antiguos:

Eliminado/Deprecado	Reemplazo Recomendado	Razón
javax.* packages	jakarta.* packages	Migración Jakarta EE 11
JUnit 4	JUnit 5	Características modernas de testing
Jackson 2.x	Jackson 3.x	Mejoras de rendimiento y seguridad
XML Configuration (MVC)	Java-based Config	Configuración type-safe
spring-jcl	Apache Commons Logging	Simplificación de logging
suffixPatternMatch	Explicit media types	Claridad en routing
trailingSlashMatch	URI templates	Comportamiento predecible

Este proceso de limpieza no solo mejora la coherencia, sino que refuerza la idea de un framework minimalista, modular y preparado para el futuro.

---

8. Estrategia de Migración: Un Enfoque Pragmático

Checklist Completo de Migración

Antes de actualizar tu aplicación a Spring Boot 4, sigue esta lista de verificación estructurada:

Fase 1: Preparación (Ahora - Octubre 2025)

1. ✅ Actualiza a JDK 17+ (preferiblemente JDK 21 o 25)
2. ✅ Migra tests de JUnit 4 a JUnit 5
3. ✅ Revisa dependencias obsoletas
4. ✅ Audita uso de javax.* packages

Fase 2: Migración de Código (Noviembre 2025 - Enero 2026)

5. ✅ Sustituye javax.* por jakarta.*
6. ✅ Actualiza Jackson 2.x a Jackson 3.x
7. ✅ Actualiza Hibernate a versión 7.0
8. ✅ Elimina configuraciones XML y migra a Java Config
9. ✅ Revisa path matching deprecated (suffixPatternMatch, trailingSlashMatch)

Fase 3: Optimización (Febrero - Abril 2026)

10. ✅ Implementa API versioning nativo donde sea apropiado
11. ✅ Migra a clientes HTTP declarativos (@HttpServiceClient)
12. ✅ Agrega anotaciones de resiliencia (@Retryable, @ConcurrencyLimit)
13. ✅ Configura observabilidad con Micrometer 2 y OpenTelemetry
14. ✅ Valida hints de GraalVM si usas imágenes nativas
15. ✅ Prueba AOT compilation para reducir tiempo de arranque

Nota importante: Spring Boot 3.5.x tendrá soporte OSS hasta junio de 2026. La transición se puede planificar de forma gradual sin presión inmediata.

Patrón de Migración Incremental

En lugar de un enfoque big-bang, considera una migración módulo por módulo:

// Phase 1: Foundation modules
@Configuration
public class CoreInfrastructureConfig {
    // Migrate core infrastructure first:
    // - Database connections
    // - Security configuration  
    // - Logging setup
}

// Phase 2: Service layer
@Service
@EnableResilientMethods
public class BusinessService {
    // Add resilience annotations
    @Retryable(maxAttempts = 3)
    @ConcurrencyLimit(10)
    public Result processBusinessLogic() {
        // Business logic
    }
}

// Phase 3: API layer
@RestController
@RequestMapping("/api/resources")
public class ApiController {
    // Implement API versioning
    @GetMapping(version = "1")
    public ResourceV1 getResourceV1() { }
    
    @GetMapping(version = "2")
    public ResourceV2 getResourceV2() { }
}

Mitigación de Riesgos con Testing

Implementar estrategias comprensivas de testing para validar la migración:

@SpringBootTest
class BackwardCompatibilityTest {
    
    @Autowired
    private TestRestTemplate restTemplate;
    
    @Test
    @DisplayName("Should maintain backward compatibility with v1 API")
    void shouldMaintainV1Compatibility() {
        ResponseEntity<String> response = restTemplate.getForEntity(
            "/api/v1/accounts/123", String.class);
        
        assertThat(response.getStatusCode()).isEqualTo(HttpStatus.OK);
        assertThat(response.getBody()).contains("accountId");
    }
    
    @Test
    @DisplayName("Should support new v2 API features")
    void shouldSupportV2Features() {
        HttpHeaders headers = new HttpHeaders();
        headers.set("Accept", "application/vnd.company.v2+json");
        
        HttpEntity<?> entity = new HttpEntity<>(headers);
        ResponseEntity<String> response = restTemplate.exchange(
            "/api/accounts/123", HttpMethod.GET, entity, String.class);
        
        assertThat(response.getBody()).contains("enhancedMetadata");
    }
}

---

9. Preparación para el Futuro: Longevidad Arquitectural

Patrones Cloud-Native

La evolución del framework soporta patrones arquitecturales cloud-native modernos:

1. Cumplimiento Twelve-Factor: Externalización de configuración y diseño sin estado
2. Optimización de contenedores: Reducción de tamaño de imagen y arranque más rápido
3. Integración Service Mesh: Soporte integrado para trazado distribuido y métricas
4. Arquitectura dirigida por eventos: Capacidades mejoradas de messaging y streaming

Alineación Tecnológica Estratégica

Spring Boot 4 posiciona aplicaciones para adopción futura de tecnología:

• Kubernetes-native: Optimizado para orquestación de contenedores
• Serverless-ready: Compatibilidad Function-as-a-Service con arranque sub-segundo
• Integración AI/ML: Hooks iniciales para componentes Spring AI
• Programación reactiva: Capacidades WebFlux mejoradas con mejor interoperabilidad

---

10. Reflexiones Finales: Código Como Lenguaje de Arquitectura

Spring Boot 4 y Spring Framework 7 representan una filosofía madura de diseño: menos configuración, más intención.

El framework ya no se limita a proporcionar abstracciones; ahora proporciona un lenguaje para la arquitectura, uno que habla en términos de resiliencia, observabilidad y claridad semántica.

Como diría Venkat Subramaniam:

"El código elegante no es solo el que funciona, sino el que invita a ser comprendido y extendido con confianza."

Spring 7 materializa esa filosofía en cada aspecto: desde el versionado declarativo de APIs hasta la resiliencia integrada, desde la observabilidad nativa hasta la seguridad mejorada con null-safety.

El Valor Estratégico de la Inversión

El esfuerzo de migración no es meramente una actualización técnica—es una inversión estratégica en:

• Eficiencia operacional: Reducción del 50-70% en costos de infraestructura con imágenes nativas
• Productividad de desarrollador: 30-40% menos código boilerplate con APIs declarativas
• Resiliencia de sistema: Patrones integrados reducen incidentes de producción
• Flexibilidad arquitectural: Soporte para patrones serverless y edge computing
• Velocidad de innovación: Time-to-market reducido con herramientas modernas

Liderazgo Técnico en la Era Cloud-Native

Las organizaciones que adopten estos cambios obtendrán ventajas competitivas medibles:

1. Reducción de TCO (Total Cost of Ownership): Menor uso de recursos computacionales
2. Mejora en SLA: Mayor uptime con patrones de resiliencia integrados
3. Aceleración del desarrollo: APIs más expresivas y menos configuración
4. Atracción de talento: Stack tecnológico moderno atrae mejores desarrolladores

---

11. Conclusión: El Futuro del Desarrollo Java

El salto hacia Spring Boot 4 y Spring Framework 7 es un recordatorio de que el ecosistema Java sigue vivo, evolucionando con los estándares modernos y anticipando las necesidades del futuro.

Con una base técnica moderna (Java 25, Jakarta EE 11, Kotlin 2.2), herramientas centradas en la productividad (HTTP Clients declarativos, AOT compilation, Observabilidad integrada) y un corazón filosófico que busca la simplicidad, estas versiones sientan las bases para la próxima década del desarrollo empresarial en Java.

La pregunta no es si migrar, sino qué tan rápidamente puedes ejecutar una estrategia de migración bien planificada. Los frameworks proporcionan la fundación; la excelencia de implementación depende de prácticas de ingeniería disciplinadas y pensamiento estratégico.

Comienza tu journey con proyectos piloto, mide los beneficios cuantitativamente, y escala el enfoque a través de tu arquitectura empresarial. El futuro del desarrollo Java está aquí—la pregunta es si liderarás la transformación o la seguirás.

El futuro del desarrollo Java no solo es moderno, sino profundamente humano.

---

Referencias y Recursos

• Spring Boot 4.0 Reference Documentation
• Spring Framework 7.0 Reference Documentation
• Spring Framework 7.0 Release Notes
• Spring Boot 4.0 Release Notes
• GraalVM Native Image Documentation
• OpenTelemetry Java Documentation