Hace tiempo descubrí lombok Empecé a encontrármelo en muchos códigos de ejemplo que iba mirando por ahí. Primero eché pestes ¿Por qué tengo que andar bajándome librerías extrañas para ejecutar pequeños códigos de ejemplo tontos?
Sin embargo, veía que se usaba bastante en muchos sitios y yo no la conocía, así que me puse a mirar qué demonios hacía … Y me encantó, descubrí por qué la gente la usa tanto.
En nuestro código java siempre tenemos que andar poniendo métodos set y métodos get, son las buenas costumbres. También constructores con parámetros para rellenar esos atributos de las clases. El famoso método toString() que saca esos atributos por pantalla y que muchas veces nos ayuda en depuración. Los métodos hashcode y equals que siempre van de la mano. Y un largo etcétera.
Los IDE dan soporte para esto. Siempre tienen opciones para generar todo este código automáticamente. Sin embargo, eso tiene una pega. Aparte de la «molestia» de andar por los menús del IDE para encontrar la opción, el código suele quedar muy extenso. Imagina una simple clase con cuatro o cinco atributos que simplemente es una estructura de datos. Hay que meterle cuatro métodos set, cuatro métodos get, el toString, el hashcode y equals de aquellos atributos que consideremos relevantes para decidir si dos estructuras de datos son iguales, constructores. Lo que era una clase de algo más de cuatro líneas puede llegar a tener .. ¿30 líneas? ¿40 líneas? de código generado por el IDE y cuya lectura no nos aporta nada. Solo «complica» la lectura de la clase.
Y eso es lo que evita lombok. Tiene muchas opciones, pero por ejemplo, si a la clase anterior le ponemos la anotación @Data, esa clase automáticamente al compilar tiene todos los métodos que hemos dicho. El código fuente queda solo con sus algo más de cuatro líneas de código, pero tenemos todos estos métodos disponibles.
El código adicional se mete en el .class al compilar. No estará en el .java. Y de aquí las pequeñas pegas de lombok, pero que, en mi opinión, creo que se pueden llevar bien:
- Como es un proceso de compilado adicional, se suele hacer con lo que se llaman annotation processor. Son procesos que durante el compilado revisan las anotaciones de las clases para hacer «cosas» adicionales. Así que requiere que habilitemos esto en maven/gradle o nuestro IDE favorito.
- Al no estar el código en los fuentes, el IDE no lo encuentra, por lo que nos dará error si intentamos usar por ejemplo un método set generado por lombok. Afortunadamente los IDE contemplan a lombok. No he mirado el caso de eclipse, pero en idea existe un plugin de lombok y tiene las opciones de habilitar el annotation processor.
Si quieres, aquí tienes más detalles y ejemplos de lombok.