Historia para Nerds. Hoy les ofrecemos: Spring y Spring Boot

Antes de Spring: Java enterprise era más áspero

Para entender por qué Spring pegó tan fuerte, hay que mirar un poco el paisaje anterior. A fines de los 90 y principios de los 2000, el desarrollo empresarial en Java estaba muy asociado a J2EE, servidores de aplicaciones pesados, despliegues en WAR o EAR, mucho XML, JNDI, EJB y una cantidad de configuración que por momentos parecía más una ceremonia administrativa que programación.

No es que Java EE no tuviera potencia. La tenía. El tema era la fricción. Para resolver problemas simples muchas veces terminabas montando una infraestructura enorme, con objetos difíciles de probar y una dependencia fuerte del servidor de aplicaciones. Era como llevar una retroexcavadora para plantar una albahaca: técnicamente se puede, pero capaz te estás complicando un poquito.

Spring nació como reacción a esa complejidad accidental. Rod Johnson empezó a trabajar en el código original en 2001 y lo publicó junto con su libro de 2002. La idea no era hacer “otro framework porque sí”, sino ofrecer una alternativa más liviana, más testeable y más flexible para construir aplicaciones empresariales sin cargar con tanto ritual innecesario.

Entonces, ¿qué es exactamente Spring?

Spring Framework es la base del ecosistema. Su pieza central es el IoC Container, también conocido como contenedor de inversión de control. Dicho sin corbata: en vez de que tus clases creen y administren todo lo que necesitan, Spring se encarga de crear objetos, conectarlos, configurarlos y entregarlos donde corresponda.

Eso permite escribir código más desacoplado. Una clase no tiene que saber cómo se construye todo el universo que la rodea; simplemente declara lo que necesita. Spring arma el cableado. Y cuando querés testear, podés reemplazar dependencias reales por mocks o implementaciones alternativas sin demoler media aplicación.

Las ideas fuertes de Spring

¿Y Spring Boot qué agrega?

Spring Boot no reemplaza a Spring. Lo simplifica. Apareció para que arrancar una aplicación Spring no fuera una procesión de configuración inicial. Boot mira qué dependencias tenés, aplica convenciones razonables, autoconfigura lo común y te permite levantar una app ejecutable sin depender necesariamente de un servidor externo.

Si Spring te da una cocina profesional, Boot te deja varias cosas listas para que no tengas que empezar fabricando la hornalla. Agregás un starter web, corrés el main, y tenés una app escuchando en el puerto 8080. No será Netflix, pero para arrancar ya es bastante más digno que pelearte con XML hasta las dos de la mañana.

Las tres bombas de productividad de Spring Boot

Historia corta de Spring: del barro J2EE al presente

Spring no nació como moda. Nació porque había dolor real. Mucha gente construyendo aplicaciones Java empresariales sentía que la infraestructura se comía al producto. Spring propuso un modelo más liviano, más testeable y más orientado a objetos simples. Desde su primera versión ya tenía varias piezas que todavía reconocemos: IoC, transacciones, abstracciones JDBC, soporte DAO, AOP y una pila web.

Comentario creado por la IA, no es mío

Spring no es “el framework viejo que sigue por costumbre”. Es viejo como ese senior que vio caer tres arquitecturas, sobrevivió a cinco migraciones y todavía te arregla un incidente con dos logs y una cara de cansancio existencial.

Historia corta de Spring Boot: cuando Spring se puso cómodo

Spring Boot llegó en 2014 y cambió la experiencia diaria. Ya no se trataba solo de tener un framework potente, sino de poder crear una app funcional rápido, con menos configuración inicial y un modelo de despliegue más simple. En vez de armar todo a mano, Boot te ofrece convenciones razonables y una estructura lista para empezar.

¿Qué demonios es un release train?

En el ecosistema Spring vas a escuchar mucho la expresión release train. Suena a nombre de reunión con mucho PowerPoint, pero tiene sentido. Un release train es una forma de coordinar versiones de varios proyectos relacionados para que sean compatibles entre sí y se puedan consumir como un bloque coherente.

Por ejemplo, Spring Data tiene muchos módulos: JPA, MongoDB, Redis, JDBC, Elasticsearch y más. Cada módulo podría evolucionar a su ritmo, pero para el usuario final sería un caos andar adivinando qué versión combina con cuál. Entonces se publica un conjunto coordinado, normalmente consumido mediante un BOM (Bill of Materials), que define versiones compatibles.

Hello World real con Spring Boot

Vamos con una aplicación mínima pero funcional. La idea es levantar una web en http://localhost:8080/ que muestre un mensaje simple. No vamos a meter base de datos, seguridad, Docker, Kafka ni una arquitectura hexagonal para imprimir un saludo. Tranquilos. Todavía somos personas.

Este ejemplo usa Spring Boot 3.5.6, que requiere al menos Java 17 (aunque se recomienda Java 21, el LTS actual). Para una aplicación web clásica con Spring MVC, usamos el starter spring-boot-starter-web. Vamos a separar la clase principal de la aplicación del controlador, como se hace en proyectos reales.

Estructura mínima del proyecto

hola-spring/
├── pom.xml
└── src/
    └── main/
        ├── java/
        │   └── com/
        │       └── ejemplo/
        │           └── holaspring/
        │               ├── HolaSpringApplication.java
        │               └── HolaController.java
        └── resources/
            └── application.properties

pom.xml

<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
         https://maven.apache.org/xsd/maven-4.0.0.xsd">

    <modelVersion>4.0.0</modelVersion>

    <parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>3.5.6</version>
        <relativePath/>
    </parent>

    <groupId>com.ejemplo</groupId>
    <artifactId>hola-spring</artifactId>
    <version>0.0.1-SNAPSHOT</version>
    <name>hola-spring</name>
    <description>Hello World mínimo con Spring Boot</description>

    <properties>
        <java.version>21</java.version>
    </properties>

    <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>

        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-test</artifactId>
            <scope>test</scope>
        </dependency>
    </dependencies>

    <build>
        <plugins>
            <plugin>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-maven-plugin</artifactId>
            </plugin>
        </plugins>
    </build>

</project>

HolaSpringApplication.java

La clase principal solo arranca Spring Boot. Nada más, nada menos.

package com.ejemplo.holaspring;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;

@SpringBootApplication
public class HolaSpringApplication {

    public static void main(String[] args) {
        SpringApplication.run(HolaSpringApplication.class, args);
    }
}

HolaController.java

El controlador define qué responder a cada URL. @RestController le indica a Spring que esta clase atiende requests HTTP y devuelve el valor de cada método directamente como respuesta. @GetMapping("/") mapea el método al GET /.

package com.ejemplo.holaspring;

import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
public class HolaController {

    @GetMapping("/")
    public String home() {
        return "Hola desde Spring Boot. Si ves esto en el puerto 8080, la criatura arrancó bien.";
    }
}

application.properties

spring.application.name=hola-spring
server.port=8080

Con eso alcanza. Corrés la aplicación, entrás a http://localhost:8080/ y deberías ver el mensaje. No es la app del siglo, claro. Pero para primer contacto está perfecto: compila, levanta, escucha en 8080 y responde. Ya con eso le ganaste a unas cuantas tardes de XML del pasado.

application.properties vs application.yaml

Spring Boot permite externalizar configuración. Eso significa que podés cambiar comportamiento sin tocar código: puerto, nombre de la aplicación, perfiles, logs, base de datos, seguridad, integraciones y bastante más. Los dos formatos más comunes son application.properties y application.yaml.

spring.application.name=hola-spring
server.port=8080
logging.level.root=INFO

spring:
  application:
    name: hola-spring

server:
  port: 8080

logging:
  level:
    root: INFO

Cómo correr una aplicación Spring Boot

Una de las grandes comodidades de Boot es que tenés varias formas simples de ejecutar la app. Para desarrollo local, lo más común es correr la clase main desde el IDE o usar Maven. Para despliegue, suele aparecer el JAR ejecutable.

./mvnw spring-boot:run

./mvnw clean package
java -jar target/hola-spring-0.0.1-SNAPSHOT.jar

Tomcat, Jetty, JAR o WAR: las formas de desplegar

En una aplicación web clásica con Spring Boot, lo normal hoy es usar un servidor embebido. Eso significa que tu aplicación trae el servidor adentro. En Spring Boot 4, para aplicaciones servlet, el default habitual es Tomcat, y también podés usar Jetty si preferís cambiar el contenedor.

¿Y si quiero WAR?

Podés cambiar el packaging en Maven:

<packaging>war</packaging>

Y normalmente adaptar tu clase principal para extender SpringBootServletInitializer. Esto permite desplegar la app en un contenedor servlet externo. Es común en ambientes legacy, donde el despliegue ya está armado alrededor de Tomcat, WebLogic, WebSphere u otro bicho corporativo que nadie quiere tocar porque “si anda, no lo mires fuerte”.

Antes de entusiasmarte de más: cuatro warnings para no comprar humo

Qué te tenés que llevar de esto

• Spring nació para bajar la complejidad accidental del Java enterprise
• Spring Boot nació para bajar la complejidad de usar Spring y permitir arrancar más rápido
• La autoconfiguración ayuda mucho, pero no reemplaza entender cómo se arma la aplicación
• Los starters agrupan dependencias coherentes para casos de uso comunes
• El JAR ejecutable con servidor embebido cambió muchísimo la experiencia de correr y desplegar apps
• Los release trains ayudan a mantener compatibilidad entre proyectos del ecosistema

Comentario creado por la IA, no es mío

En otras palabras: Spring no es solo una tecnología. Es el momento en que Java enterprise dejó de decirte “primero sufrí un poco” como requisito de ingreso. Y Spring Boot es el amigo que te abre la puerta, te muestra dónde está la documentación y te dice: “dale, corré el main, después vemos”.