Lombok, explicado como si nunca hubieras oído hablar de él

1El problema: Java te obliga a escribir mucho relleno

Antes de ver la herramienta, hay que entender qué dolor quita.

En Java, casi todas las clases que guardan datos (un conductor, un vehículo, una multa…) necesitan lo mismo: campos private, un método para leer cada campo (getter), otro para cambiarlo (setter), uno o varios constructores, un toString() para poder imprimirlo y un equals()/hashCode() para poder compararlo. Ese código se llama boilerplate: relleno repetitivo que no aporta nada nuevo pero que hay que escribir, leer y mantener.

Mira la diferencia con una clase de tres campos:

public class Conductor {
    private String dni;
    private String nombre;
    private int puntos;

    public Conductor() { }

    public Conductor(String dni, String nombre, int puntos) {
        this.dni = dni;
        this.nombre = nombre;
        this.puntos = puntos;
    }

    public String getDni() { return dni; }
    public void setDni(String dni) { this.dni = dni; }

    public String getNombre() { return nombre; }
    public void setNombre(String nombre) { this.nombre = nombre; }

    public int getPuntos() { return puntos; }
    public void setPuntos(int puntos) { this.puntos = puntos; }

    @Override
    public String toString() {
        return "Conductor(dni=" + dni + ", nombre=" + nombre
             + ", puntos=" + puntos + ")";
    }

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (!(o instanceof Conductor)) return false;
        Conductor c = (Conductor) o;
        return puntos == c.puntos
            && Objects.equals(dni, c.dni)
            && Objects.equals(nombre, c.nombre);
    }

    @Override
    public int hashCode() {
        return Objects.hash(dni, nombre, puntos);
    }
}

import lombok.AllArgsConstructor;
import lombok.Data;
import lombok.NoArgsConstructor;

@Data
@NoArgsConstructor
@AllArgsConstructor
public class Conductor {
    private String dni;
    private String nombre;
    private int puntos;
}

2¿Cómo funciona por dentro? (sin magia negra)

Saber esto te ahorra muchos sustos cuando algo «no compila».

Las cosas que empiezan por @ se llaman anotaciones: son etiquetas que pegas encima de una clase, campo o método. Por sí solas no hacen nada; alguien tiene que leerlas.

Lombok es un procesador de anotaciones: un programa que se «cuela» en el compilador de Java (javac). Cuando compilas, Lombok lee tus etiquetas y añade el código que falta antes de que se genere el .class. Resultado:

• En tu fichero .java no verás los getters: el fuente se queda corto y limpio.
• En el .class compilado sí están, como si los hubieras escrito tú.
• Cuando el programa se ejecuta, Lombok ya no pinta nada: por eso en Maven se declara con <scope>provided</scope> (se usa al compilar, no se empaqueta en el .jar final).

3Instalarlo en un proyecto Maven / Spring Boot

Dos piezas: la dependencia y avisar al compilador.

Si creas el proyecto con Spring Initializr y marcas la dependencia Lombok, ya viene todo hecho. Si lo añades a mano, en el pom.xml:

<!-- 1) La dependencia: solo hace falta al compilar -->
<dependency>
    <groupId>org.projectlombok</groupId>
    <artifactId>lombok</artifactId>
    <scope>provided</scope>   <!-- en Spring Boot la versión la pone el padre -->
</dependency>

<!-- 2) Registrarlo como procesador de anotaciones (obligatorio desde JDK 23) -->
<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-compiler-plugin</artifactId>
    <configuration>
        <annotationProcessorPaths>
            <path>
                <groupId>org.projectlombok</groupId>
                <artifactId>lombok</artifactId>
            </path>
        </annotationProcessorPaths>
    </configuration>
</plugin>

El IDE también tiene que enterarse

• IntelliJ IDEA: el soporte de Lombok viene incluido. Si te pregunta, acepta «Enable annotation processing» (Settings → Build → Compiler → Annotation Processors).
• VS Code: el Extension Pack for Java ya entiende Lombok.
• Eclipse: hay que ejecutar el instalador de Lombok (java -jar lombok.jar) y reiniciar.

Si el IDE no está configurado, el proyecto compila con Maven pero el editor te lo llena todo de rojo porque «no ve» los métodos generados.

4@Getter y @Setter: leer y cambiar campos

Las más básicas. Todo lo demás se construye sobre ellas.

Puedes ponerlas sobre la clase (afectan a todos los campos) o sobre un campo (solo a ese).

@Getter                       // getters para TODOS los campos
public class Vehiculo {
    private String matricula;
    @Setter private String color; // setter SOLO para color
    private boolean electrico;
}

// Lombok genera:
//   getMatricula(), getColor(), isElectrico()   ← boolean usa "is"
//   setColor(String)

• Para un boolean (primitivo) el getter se llama isElectrico(), no getElectrico(). Es la convención de Java.
• Los campos final nunca tienen setter (no se pueden cambiar, así que no tendría sentido).
• Se puede cambiar la visibilidad: @Setter(AccessLevel.PROTECTED) genera un setter protected; AccessLevel.NONE hace que no se genere para ese campo.
• Si tú escribes a mano un método con el mismo nombre, Lombok respeta el tuyo y no genera ese.

5@ToString: que al imprimirlo se entienda algo

Sin él, imprimir un objeto da algo como Conductor@1b6d3586.

@ToString
@AllArgsConstructor
public class Usuario {
    private String login;
    @ToString.Exclude private String password;  // ¡nunca al log!
}

System.out.println(new Usuario("ana", "1234"));
// → Usuario(login=ana)

Usa @ToString.Exclude para dos cosas: datos sensibles (contraseñas, tokens) y relaciones entre objetos que se apuntan mutuamente (lo verás en las trampas, sección 14).

6@EqualsAndHashCode: cuándo dos objetos son «el mismo»

Importante en cuanto metes objetos en un Set o de clave en un Map.

En Java, == compara si son el mismo objeto en memoria. equals() compara si son iguales en contenido. Por defecto (sin sobrescribirlo), equals() se comporta como ==, y eso casi nunca es lo que quieres: dos Matricula("1234ABC") creadas por separado deberían considerarse iguales.

hashCode() es un número «resumen» del objeto que usan HashSet y HashMap para encontrarlo rápido. La regla de oro: si dos objetos son equals, deben tener el mismo hashCode. Por eso siempre van juntos, y por eso Lombok los genera a la vez.

@EqualsAndHashCode(onlyExplicitlyIncluded = true)
public class Conductor {
    @EqualsAndHashCode.Include private String dni;  // solo el DNI decide
    private String nombre;
    private int puntos;
}
// Dos conductores con el mismo DNI son iguales aunque tengan distintos puntos.

• Por defecto usa todos los campos no static ni transient.
• Puedes quitar campos con @EqualsAndHashCode.Exclude o, como arriba, decir «solo los que yo marque».
• Si tu clase hereda de otra, Lombok te avisará: por defecto ignora los campos del padre. Añade callSuper = true si esos campos también deben contar.

7Los tres constructores

Cada uno crea un constructor distinto. Se pueden combinar.

El caso estrella: servicios de Spring

En Spring, un servicio necesita otros objetos (un repositorio, un validador…). La forma recomendada de recibirlos es por constructor, con campos final. @RequiredArgsConstructor te escribe ese constructor:

@Service
public class ExpedienteService {
    private final ExpedienteRepository repo;
    private final NotificacionService avisos;

    public ExpedienteService(ExpedienteRepository repo,
                             NotificacionService avisos) {
        this.repo = repo;
        this.avisos = avisos;
    }
}

@Service
@RequiredArgsConstructor
public class ExpedienteService {
    private final ExpedienteRepository repo;
    private final NotificacionService avisos;
}

8@Data: el «todo en uno»

La más famosa y, precisamente por eso, la que más se usa mal.

@Data es un atajo que equivale a poner a la vez:

@Getter                  // en todos los campos
@Setter                  // en todos los campos NO final
@ToString
@EqualsAndHashCode
@RequiredArgsConstructor

Perfecta para clases que solo transportan datos y cambian: un formulario, un objeto que rellenas por partes, un DTO mutable…

9@Value y su primo moderno, el record

Para datos que, una vez creados, no cambian (inmutables).

@Value es la versión «de solo lectura» de @Data: todos los campos pasan a ser private final, la clase se vuelve final, genera getters, toString, equals/hashCode y un constructor con todos los campos, y no genera setters.

@Value
public class Coordenadas {
    double latitud;
    double longitud;
}
// c.getLatitud()

public record Coordenadas(double latitud,
                          double longitud) { }
// c.latitud()   ← sin "get"

10@Builder: crear objetos con muchos campos sin volverse loco

Adiós a los new Multa(null, 200, null, "A-12", true, null).

Cuando un constructor tiene muchos parámetros, es muy fácil equivocarse de orden (¿el 3º era el importe o los puntos?). El patrón Builder te deja nombrar cada valor:

@Builder(toBuilder = true)
@Getter
public class Multa {
    private String matricula;
    private double importe;
    private int puntos;
    @Builder.Default private boolean pagada = false;
}

Multa m = Multa.builder()
        .matricula("1234ABC")
        .importe(200)
        .puntos(4)
        .build();          // pagada = false (gracias a @Builder.Default)

Multa pagada = m.toBuilder().pagada(true).build(); // copia con pagada = true

• Los campos que no pongas quedan con su valor «vacío» (null, 0, false)… aunque les hayas dado un valor inicial, salvo que lleven @Builder.Default.
• @Builder(toBuilder = true) añade toBuilder(): crea una copia del objeto para cambiarle algo. Muy útil con objetos inmutables.
• @Singular sobre una lista te permite añadir elementos uno a uno: .alegacion(a1).alegacion(a2).

11@Slf4j: un logger gratis

Para escribir mensajes de log en vez de System.out.println.

@Slf4j
@Service
public class RadarService {
    public void procesar(Denuncia d) {
        log.info("Procesando denuncia {}", d.id());
        log.debug("Detalle: {}", d);
    }
}

// Lombok añade por ti:
// private static final org.slf4j.Logger log =
//         org.slf4j.LoggerFactory.getLogger(RadarService.class);

La variable siempre se llama log. Las llaves {} se sustituyen por los argumentos, en orden. Spring Boot ya trae SLF4J, así que funciona sin añadir nada.

12Otras que te vas a cruzar

No son las del día a día, pero conviene reconocerlas.

13Recetas: qué poner según el tipo de clase

Combinaciones que funcionan bien en un proyecto Spring Boot.

// Entidad JPA "segura" con Lombok
@Entity
@Getter @Setter
@NoArgsConstructor
@ToString
public class Conductor {
    @Id @GeneratedValue
    private Long id;
    private String dni;
    private String nombre;

    @ToString.Exclude
    @OneToMany(mappedBy = "conductor")
    private List<Multa> multas = new ArrayList<>();
}

14Trampas típicas (y cómo salir de ellas)

Lo que suele costar una tarde entera de depuración.

1. «cannot find symbol: getNombre()» aunque tengo @Data

Lombok no se está ejecutando al compilar. Casi siempre es que falta el bloque annotationProcessorPaths del pom.xml (sección 3), sobre todo con Java 23 o superior. Si solo falla en el editor pero ./mvnw compile va bien, es el IDE: activa el procesamiento de anotaciones.

2. StackOverflowError al imprimir o al meter en un Set

Si un Conductor tiene una lista de Multa y cada Multa apunta a su Conductor, el toString() del conductor imprime sus multas, que imprimen su conductor, que imprime sus multas… hasta reventar. Con equals/hashCode pasa lo mismo. Solución: excluye la relación en al menos un lado con @ToString.Exclude y @EqualsAndHashCode.Exclude.

3. @Data en entidades JPA

Además del bucle anterior, en JPA el equals/hashCode que usa todos los campos da problemas: el id cambia de null a un número al guardar (el objeto «cambia de identidad» dentro de un HashSet), y leer relaciones perezosas (lazy) desde toString puede lanzar consultas extra o LazyInitializationException. Por eso la recomendación habitual es @Getter @Setter @NoArgsConstructor y escribir equals/hashCode con cuidado (o no sobrescribirlos).

4. @Builder junto a @NoArgsConstructor no compila

@Builder necesita un constructor con todos los campos. Solo lo crea él mismo si tú no has declarado otro constructor. En cuanto añades @NoArgsConstructor, deja de hacerlo. Solución: añade también @AllArgsConstructor.

5. Mi valor por defecto desaparece con el builder

private boolean pagada = false; se ignora al usar builder(). Añade @Builder.Default encima del campo.

15Chuleta para el examen

Una línea por anotación.

≈Similitudes: cosas de Java que ya conoces (o conocerás) y se parecen

Para situar Lombok en el mapa: qué más resuelve el mismo problema y en qué se diferencia.

1. record: la alternativa oficial de Java a @Value (y a medio @Data)

Desde Java 16, un record es una clase especial pensada para guardar datos que no cambian. Con una sola línea, Java genera por ti el constructor con todos los campos, un método de lectura por campo, toString(), equals() y hashCode(). Es decir: casi lo mismo que @Value, pero sin ninguna librería.

@Data
@NoArgsConstructor
@AllArgsConstructor
public class Conductor {
    private String dni;
    private String nombre;
    private int puntos;
}

c.getNombre();
c.setPuntos(8);     // se puede cambiar

public record Conductor(String dni,
                        String nombre,
                        int puntos) {
    // Validación opcional en el "constructor compacto"
    public Conductor {
        if (puntos < 0) throw new IllegalArgumentException();
    }
}

c.nombre();         // sin "get"
c.withPuntos(8);    // ✗ no existe: hay que crear otro
new Conductor(c.dni(), c.nombre(), 8);

2. El generador de código del IDE (Alt+Insert en IntelliJ)

IntelliJ, Eclipse y VS Code tienen un menú Generate que escribe getters, setters, constructores, toString, equals y hashCode con un par de clics. El resultado final es el mismo que con Lombok, pero con una diferencia clave:

• IDE: el código se escribe de verdad en tu fichero. Lo ves y lo puedes tocar, pero ocupa mucho y, si añades un campo, tienes que acordarte de regenerarlo (equals desactualizado = error silencioso).
• Lombok: el código no está en tu fichero, se genera al compilar. La clase se queda corta y siempre al día, pero «no ves» lo que hay.

Consejo de profe: escribe a mano o con el IDE una clase completa al menos una vez. Si entiendes lo que Lombok te ahorra, sabrás arreglarlo cuando falle.

3. @Override y los métodos de Object

Ya has usado anotaciones: @Override es una. La diferencia es que @Override solo comprueba (el compilador se queja si el método no sobrescribe nada), mientras que las de Lombok generan código.

Y lo que genera no es nada nuevo: toda clase de Java hereda de Object los métodos toString(), equals() y hashCode(). @ToString y @EqualsAndHashCode simplemente los sobrescriben por ti, igual que harías tú con @Override.

4. @Autowired en Spring frente a @RequiredArgsConstructor

En tutoriales antiguos verás las dependencias inyectadas así: @Autowired private ExpedienteRepository repo;. Funciona, pero el campo no puede ser final y la clase es difícil de probar sin Spring. La práctica recomendada hoy es la inyección por constructor, y @RequiredArgsConstructor la deja igual de corta que @Autowired pero con campos final. Mismo objetivo, forma más segura.

★Fuentes

• Documentación oficial de Lombok: lista de funcionalidades, @Data, constructores, @EqualsAndHashCode, @Value, @Builder, @Log / @Slf4j.
• Instalación con Maven y el requisito de JDK 23: projectlombok.org/setup/maven.
• Records de Java: JEP 395.