¿Es seguro usar el Proyecto Lombok?

En caso de que no lo sepas, el Proyecto Lombok ayuda con algunas de las molestias de Java con cosas como generar getters y setters con anotaciones e incluso generación simple de JavaBean con @Data . Realmente podría ayudarme, especialmente en 50 objetos de eventos diferentes donde tienes hasta 7 campos diferentes que necesitan construirse y ocultarse con getters. Podría eliminar casi mil líneas de código con esto.

Sin embargo, me preocupa que, a la larga, será una decisión lamentable. Flamewars entrará en erupción en el canal ##Java Freenode cuando lo mencione, ya que proporcionar fragmentos de código confundirá a los posibles ayudantes, las personas se quejarán de que faltan JavaDoc , y los futuros commiters podrían simplemente eliminarlo todo de todos modos. Realmente disfrutaría lo positivo, pero estoy preocupado por lo negativo.

Entonces, ¿es seguro usar Lombok en cualquier proyecto, pequeño o grande? ¿Los efectos positivos valen lo negativo?

Parece que ya ha decidido que el Proyecto Lombok le brinda importantes ventajas técnicas para su nuevo proyecto propuesto. (Para ser claro desde el principio, no tengo puntos de vista particulares sobre el Proyecto Lombok, de una forma u otra).

Antes de utilizar el Proyecto Lombok (o cualquier otra tecnología que cambie el juego) en algún proyecto (de código abierto o de otro tipo), debe asegurarse de que las partes interesadas del proyecto acepten esto. Esto incluye a los desarrolladores y a cualquier usuario importante (por ejemplo, patrocinadores formales o informales).

Usted menciona estos posibles problemas:

Flamewars entrará en erupción en el canal ## Java Freenode cuando lo mencione,

Fácil. Ignorar / no participar en los flamewars, o simplemente abstenerse de mencionar a Lombok.

proporcionar fragmentos de código confundirá a los posibles ayudantes,

Si la estrategia del proyecto es usar Lombok, entonces los posibles ayudantes deberán acostumbrarse.

la gente se quejará de la falta de JavaDoc,

Ese es su problema. Nadie en su sano juicio intenta aplicar rígidamente las reglas de código fuente / documentación de su organización al software de fuente abierta de terceros. El equipo del proyecto debe tener la libertad de establecer estándares de código fuente / documentación del proyecto que sean apropiados para la tecnología que se utiliza.

( SEGUIMIENTO : los desarrolladores de Lombok reconocen que no generar comentarios de javadoc para los métodos sintetizados getter y setter es un problema. Si este es un problema importante para su (s) proyecto (s), entonces una alternativa es crear y enviar un parche Lombok para abordar esto. )

y los futuros comprometidos podrían simplemente eliminarlo todo de todos modos.

Eso no es todo! Si la estrategia de proyecto acordada es usar Lombok, los comisionados que detuvieron el código de forma gratuita deben ser castigados y, si es necesario, se les retiran sus derechos de compromiso.

Por supuesto, esto supone que tiene participación de los interesados ​​… incluidos los desarrolladores. Y asume que estás preparado para argumentar tu causa y manejar apropiadamente las inevitables voces disidentes.

Acabo de empezar a usar Lombok hoy. Hasta ahora me gusta, pero un inconveniente que no vi mencionado fue el apoyo de refactorización.

Si tiene una clase anotada con @Data , generará getters y setters basados ​​en los nombres de los campos. Si usa uno de esos captadores en otra clase, entonces decida que el campo está mal nombrado, no encontrará usos de esos captadores y establecedores y reemplazará el nombre antiguo con el nuevo.

Me imagino que esto tendría que hacerse a través de un complemento IDE y no a través de Lombok.

ACTUALIZACIÓN (22 de enero de 2013)
Después de usar Lombok por 3 meses, aún así lo recomiendo para la mayoría de los proyectos. Sí encontré, sin embargo, otro inconveniente similar al mencionado anteriormente.

Si tiene una clase, diga MyCompoundObject.java que tiene 2 miembros, ambos anotados con @Delegate , digamos myWidgets y myGadgets , cuando llame a myCompoundObject.getThingies() desde otra clase, es imposible saber si está delegando en el Widget o Gadget porque ya no puede saltar a la fuente dentro del IDE.

El uso de Eclipse “Generar métodos delegates …” le proporciona la misma funcionalidad, es igual de rápido y proporciona salto de fuente. El inconveniente es que desordena su fuente con un código estándar que quita el foco de las cosas importantes.

ACTUALIZACIÓN 2 (26 de febrero de 2013)
Después de 5 meses, todavía estamos usando Lombok, pero tengo algunas otras molestias. La falta de un getter & setter declarado puede ser molesto a veces cuando intenta familiarizarse con el nuevo código.

Por ejemplo, si veo un método llamado getDynamicCols() pero no sé de qué se trata, tengo algunos obstáculos adicionales para saltar para determinar el propósito de este método. Algunos de los obstáculos son Lombok, algunos son la falta de un plugin inteligente de Lombok. Los obstáculos incluyen:

  • La falta de JavaDocs. Si hago un javadoc en el campo, espero que getter y setter hereden ese javadoc a través del paso de comstackción de Lombok.
  • Ir a la definición del método me lleva a la clase, pero no a la propiedad que generó el getter. Este es un problema de complemento.
  • Obviamente, no puede establecer un punto de interrupción en un getter / setter a menos que genere o codifique el método.
  • NOTA: Esta búsqueda de referencia no es un problema como pensé en un principio. Sin embargo, debe utilizar una perspectiva que habilite la vista de esquema. No es un problema para la mayoría de los desarrolladores. Mi problema era que estoy usando Mylyn, que estaba filtrando mi vista de Outline , así que no vi los métodos. La falta de búsqueda de referencias. Si quiero ver quién llama getDynamicCols(args...) , tengo que generar o codificar el setter para poder buscar referencias.

ACTUALIZACIÓN 3 (7 de marzo de 2013)
Aprender a usar las diversas formas de hacer las cosas en Eclipse, supongo. En realidad, puede establecer un punto de interrupción condicional (BP) en un método generado Lombok. Con la vista de Outline , puede hacer clic con el botón derecho en el método para Toggle Method Breakpoint . Luego, cuando acierte BP, puede usar la vista de Variables depuración para ver qué método generó el nombre de los parámetros (generalmente el mismo nombre del campo) y, finalmente, usar la vista Breakpoints para hacer clic con el botón secundario en BP y seleccionar Breakpoint Properties... para agregar una condición. Bonito.

ACTUALIZACIÓN 4 (16 de agosto de 2013)
A Netbeans no le gusta cuando actualizas tus dependencias Lombok en tu Maven pom. El proyecto aún comstack, pero los archivos se marcan por tener errores de comstackción porque no puede ver los métodos que Lombok está creando. Borrar el caché de Netbeans resuelve el problema. No estoy seguro de si hay una opción de “Proyecto limpio” como la que hay en Eclipse. Problema menor, pero quería darlo a conocer.

ACTUALIZACIÓN 5 (17 de enero de 14)
Lombok no siempre juega bien con Groovy, o al menos con el groovy-eclipse-compiler . Es posible que deba degradar su versión del comstackdor. Maven Groovy y Java + Lombok

ACTUALIZACIÓN 6 (26 de junio de 14)
Una palabra de advertencia. Lombok es un poco adictivo y si trabajas en un proyecto donde no puedes usarlo por alguna razón, te molestará. Puede ser mejor que nunca lo uses en absoluto.

ACTUALIZACIÓN 7 (23 de julio de 14)
Esta es una actualización bastante interesante porque aborda directamente la seguridad de la adopción de Lombok sobre la cual el OP preguntó.

A partir de v1.14, la anotación @Delegate ha sido degradada a un estado Experimental. Los detalles están documentados en su sitio ( Lombok Delegate Docs ).

El caso es que si usaba esta función, sus opciones de retroceso son limitadas. Veo las opciones como:

  • Elimine manualmente las anotaciones @Delegate y genere / codifique manualmente el código de delegado. Esto es un poco más difícil si estaba usando atributos dentro de la anotación.
  • Elimine los archivos que tienen la anotación @Delegate y tal vez agregue nuevamente las anotaciones que desea.
  • Nunca actualice Lombok o mantenga un tenedor (o viva con el uso de características de experiencia).
  • Delombok todo tu proyecto y deja de usar Lombok.

Por lo que puedo decir, Delombok no tiene una opción para eliminar un subconjunto de anotaciones ; es todo o nada al menos para el contexto de un solo archivo. Abrí un boleto para solicitar esta función con banderas de Delombok, pero no lo esperaría en el futuro cercano.

ACTUALIZACIÓN 8 (20 de octubre de 2014)
Si se trata de una opción para usted, Groovy ofrece la mayoría de los mismos beneficios de Lombok, además de una gran cantidad de otras funciones, incluida @Delegate . Si cree que le resultará difícil vender la idea a los poderes fácticos, eche un vistazo a la anotación @CompileStatic o @TypeChecked para ver si eso puede ayudar a su causa. De hecho, el foco principal de la versión 2.0 de Groovy era la seguridad estática .

ACTUALIZACIÓN 9 (1 de septiembre de 2015)
Lombok todavía se mantiene y mejora activamente , lo que es un buen presagio para el nivel de seguridad de la adopción. Las anotaciones de @Builder es una de mis características nuevas favoritas.

ACTUALIZACIÓN 10 (17 de noviembre de 15)
Esto puede no parecer directamente relacionado con la pregunta del OP, pero vale la pena compartirlo. Si busca herramientas que lo ayuden a reducir la cantidad de código repetitivo que escribe, también puede consultar Google Auto , en particular AutoValue . Si nos fijamos en su mazo de diapositivas , la lista Lombok como una posible solución al problema que están tratando de resolver. Los inconvenientes que enumeran para Lombok son:

  • El código insertado es invisible (no se puede “ver” los métodos que genera) [Nota ed .: en realidad se puede, pero solo se necesita un descomstackdor]
  • Los piratas informáticos son no estándar y frágiles
  • “En nuestra opinión, su código ya no es realmente Java”

No estoy seguro de lo mucho que estoy de acuerdo con su evaluación. Y teniendo en cuenta los inconvenientes de AutoValue que están documentados en las diapositivas, me quedaré con Lombok (si Groovy no es una opción).

ACTUALIZACIÓN 11 (8 de febrero de16)
Descubrí que Spring Roo tiene algunas anotaciones similares . Me sorprendió un poco descubrir que Roo sigue siendo una cosa y encontrar documentación para las anotaciones es un poco duro. La eliminación tampoco parece tan fácil como de-lombok. Lombok parece ser la opción más segura.

ACTUALIZACIÓN 12 (17 de febrero de16)
Al tratar de encontrar justificaciones de por qué es seguro traer Lombok para el proyecto en el que estoy trabajando actualmente, encontré una pieza de oro que se agregó con v1.14 – ¡El sistema de configuración ! Esto significa que puede configurar un proyecto para desactivar ciertas características que su equipo considera inseguras o indeseables. Mejor aún, también puede crear configuraciones específicas de directorio con diferentes configuraciones. Esto es IMPRESIONANTE.

ACTUALIZACIÓN 13 (4 de octubre ’16)
Si este tipo de cosas le importan, Oliver Gierke sintió que era seguro agregar Lombok a Spring Data Rest .

ACTUALIZACIÓN 14 (26 de septiembre de 17)
Como señaló @gavenkoa en los comentarios sobre la pregunta de OPs, la compatibilidad con el comstackdor JDK9 aún no está disponible (Problema n. ° 985). También parece que no será una solución fácil para el equipo de Lombok.

ACTUALIZACIÓN 15 (26 de marzo de 18)
El registro de cambios de Lombok indica a partir de v1.16.20 “La comstackción de lombok en JDK1.9 ahora es posible “, aunque el # 985 todavía está abierto.

Los cambios para acomodar JDK9, sin embargo, necesitaron algunos cambios de ruptura; todo aislado a los cambios en los valores predeterminados de configuración. Es un poco preocupante que hayan introducido cambios de última hora, pero la versión solo superó el número de versión “Incremental” (pasando de v1.16.18 a v1.16.20). Como esta publicación era sobre la seguridad, si tuvieras un sistema de comstackción de yarn/npm que se actualizara automáticamente a la última versión incremental, podrías tener un rudo despertar.

Adelante y usa Lombok, si es necesario “delombok” luego tu código http://projectlombok.org/features/delombok.html

Personalmente (y, por lo tanto, subjetivamente), he descubierto que el uso de Lombok hace que mi código sea más expresivo sobre lo que bash lograr cuando se compara con las implementaciones IDE / propias de métodos intrincados como hashcode & equals.

Cuando usas

 @EqualsAndHashCode(callSuper = false, of = { "field1", "field2", "field3" }) 

es mucho más fácil mantener Equals & HashCode constante y realizar un seguimiento de los campos que se evalúan, que cualquier implementación IDE / propia. Esto es especialmente cierto cuando aún agrega / elimina campos regularmente.

Lo mismo ocurre con la anotación @ToString y sus parámetros que comunican claramente el comportamiento deseado con respecto a los campos incluidos / excluidos, el uso de captadores o el acceso de campo y si se debe o no a llamar a super.toString() .

Y de nuevo anotando una clase completa con @Getter o @Setter(AccessLevel.NONE) (y opcionalmente anulando cualquier método divergente) queda claro inmediatamente qué métodos estarán disponibles para los campos.

Los beneficios siguen y siguen …

En mi opinión, no se trata de reducir el código, sino de comunicar claramente lo que desea lograr, en lugar de tener que resolverlo desde Javadoc o implementaciones. El código reducido solo hace que sea más fácil detectar cualquier implementación de método divergente.

Lombok es genial, pero …

Lombok rompe las reglas del procesamiento de anotaciones, ya que no genera nuevos archivos fuente. Esto significa que no se puede usar con otros procesadores de anotaciones si esperan que los getters / setters o cualquier otra cosa existan.

El proceso de anotación se ejecuta en una serie de rondas. En cada ronda, cada uno tiene un turno para correr. Si se encuentran nuevos archivos java después de completar la ronda, comienza otra ronda. De esta forma, el orden de los procesadores de anotación no importa si solo generan nuevos archivos. Dado que lombok no genera ningún archivo nuevo, no se inician nuevas rondas, por lo que algunos AP que dependen del código lombok no se ejecutan como se esperaba. Esto fue una gran fuente de dolor para mí al usar Mapstruct, y delombok-ing no es una opción útil ya que destruye los números de línea en los registros.

Finalmente, pirateé un script de comstackción para trabajar con lombok y mapstruct. Pero quiero dejar lombok por lo alocado que es, al menos en este proyecto. Uso lombok todo el tiempo en otras cosas.

También hay riesgos de mantenimiento a largo plazo. Primero, recomendaría leer acerca de cómo realmente funciona Lombok, por ejemplo, algunas respuestas de sus desarrolladores aquí .

El sitio oficial también contiene una lista de inconvenientes , incluida esta cita de Reinier Zwitserloot:

Es un truco total. Usando API no pública. Presuntuoso casting (sabiendo que un procesador de anotación que se ejecuta en javac obtendrá una instancia de JavacAnnotationProcessor, que es la implementación interna de AnnotationProcessor (una interfaz), que tiene un par de métodos adicionales que se usan para acceder a la AST activa) .

En eclipse, es posiblemente peor (y aún más robusto): un agente de Java se usa para inyectar código en la clase de gramática y analizador de eclipse, que por supuesto es una API completamente no pública y totalmente fuera de los límites.

Si pudieras hacer lo que lombok hace con API estándar, lo hubiera hecho de esa manera, pero no puedes. Aún así, por lo que vale, desarrollé el plugin eclipse para eclipse v3.5 que se ejecuta en java 1.6, y sin realizar ningún cambio funcionó en eclipse v3.4 corriendo también en java 1.5, por lo que no es completamente frágil.

Como resumen, aunque Lombok puede ahorrarle algo de tiempo de desarrollo, si hay una actualización javac no compatible con versiones anteriores (por ejemplo, una mitigación de vulnerabilidad), Lombok puede hacer que se quede con una versión anterior de Java mientras los desarrolladores intentan actualizar su uso de esos API internas. Si esto es un riesgo serio obviamente depende del proyecto.

Sé que llego tarde, pero no puedo resistir la tentación: a cualquiera que le guste Lombok también debería echarle un vistazo a Scala. Muchas buenas ideas que encuentras en Lombok son parte del lenguaje Scala.

En su pregunta: definitivamente es más fácil conseguir que sus desarrolladores prueben Lombok que Scala. Pruébalo y si les gusta, prueba Scala.

Solo como un descargo de responsabilidad: ¡también me gusta Java!

Utilicé Lombok en casi todos mis proyectos durante un año, pero desafortunadamente lo eliminé. Al principio fue una forma muy limpia de desarrollo, pero establecer el entorno de desarrollo para los nuevos miembros del equipo no es muy fácil y directo. Cuando se convirtió en un dolor de cabeza, simplemente lo eliminé. Pero es un buen trabajo y necesita un poco más de simplicidad para la configuración.

Cuando mostré el proyecto a mi equipo, el entusiasmo fue alto, así que creo que no debes temer a la respuesta del equipo.

  • En cuanto al ROI, es muy fácil de integrar y no requiere cambio de código en su forma básica. (simplemente agregando una sola anotación a su clase)

  • Y por último, si cambias de opinión, puedes ejecutar el unlombok, o dejar que tu IDE cree estos setters, getters y ctors (que creo que nadie te preguntará una vez que vean cuán claro se vuelve tu pojo)

Quería usar lombok’s @ToString pero pronto se enfrentó a errores de comstackción aleatorios en la reconstrucción del proyecto en Intellij IDEA. Tuve que pulsar comstackr varias veces antes de que la comstackción incremental pudiera completarse con éxito.

Intentó tanto lombok 1.12.2 como 0.9.3 con Intellij IDEA 12.1.6 y 13.0 sin ningún plugin lombok bajo jdk 1.6.0_39 y 1.6.0_45.

Tuve que copiar manualmente los métodos generados de la fuente delombinada y poner lombok en espera hasta tiempos mejores.

Actualizar

El problema ocurre solo con la comstackción paralela habilitada.

Archivado un problema: https://github.com/rzwitserloot/lombok/issues/648

Actualizar

mplushnikov comentó el 30 de enero de 2016:

La versión más nueva de Intellij ya no tiene tales problemas. Creo que se puede cerrar aquí.

Actualizar

Recomiendo encarecidamente cambiar de Java + Lombok a Kotlin si es posible. Como ha resuelto desde cero todos los problemas de Java que Lombok intenta solucionar.

He encontrado un problema con Lombok y Jackson CSV , cuando mariscalicé mi objeto (java bean) en un archivo CSV, las columnas se duplicaron, luego eliminé la anotación @Data de Lombok y la clasificación funcionó bien.

Leí algunas opiniones sobre Lombok y, en realidad, las estoy usando en algunos proyectos.

Bueno, en el primer contacto con Lombok tuve una mala impresión. Después de algunas semanas, comencé a gustarme. Pero después de algunos meses descubro muchos pequeños problemas al usarlo. Entonces, mi impresión final sobre Lombok no es tan positiva.

Mis razones para pensar de esta manera:

  • IDE plugin dependency . El soporte IDE para Lombok es a través de complementos. Incluso trabajando bien en la mayoría de las veces, siempre eres un rehén de estos complementos que se mantendrán en las versiones futuras de los IDEs e incluso del lenguaje (Java 10+ acelerará el desarrollo del lenguaje). Por ejemplo, traté de actualizar de Intellij IDE 2017.3 a 2018.1 y no pude hacer eso porque hay un problema en la versión real del complemento lombok y necesito esperar a que el complemento se actualice … Esto también es un problema si Me gustaría utilizar un IDE más alternativo que no tenga ningún tipo de compatibilidad con el complemento de Lombok.
  • ‘Encontrar problemas de uso’. . Al usar Lombok, no ves los métodos getter, setter, constructor, builder, etc. generados. Por lo tanto, si planeas descubrir cuál de estos métodos usa tu IDE en tu proyecto, no puedes hacer esto solo. buscando la clase que posee estos métodos escondidos.
  • Tan fácil que a los desarrolladores no les importa romper la encapsulación . Sé que no es realmente un problema de Lombok. Pero vi una mayor tendencia a que los desarrolladores ya no controlen qué métodos deben ser visibles o no. Por lo tanto, muchas veces solo están copiando y pegando @Getter @Setter @Builder @AllArgsConstructor @NoArgsConstructor sin pensar qué es lo que la clase realmente necesita.
  • Builder Obssession ©. Inventé este nombre (bajar, Martin Fowler). Bromas aparte, un generador es tan fácil de crear que incluso cuando una clase tiene solo dos parámetros, los desarrolladores prefieren usar @Builder lugar de un constructor o un método de constructor estático. Algunas veces incluso intentan crear un Constructor dentro del Constructor lombok, creando situaciones extrañas como MyClass.builder().name("Name").build().create() .
  • Barreras al refacturar . Si está utilizando, por ejemplo, un @AllArgsConstructor y necesita agregar un parámetro más en el constructor, el IDE no puede ayudarle a agregar este parámetro adicional en todos los lugares (principalmente, pruebas) que crean una instancia de la clase.
  • Mezcle Lombok con métodos concretos . No puedes usar Lombok en todos los escenarios para crear un getter / setter / etc. Entonces, verás estos dos enfoques mezclados en tu código. Te acostumbras a esto después de un tiempo, pero se siente como un truco en el lenguaje.

Como dijo otra respuesta, si estás enojado por la verbosidad de Java y utilizas Lombok para lidiar con ella, prueba con Kotlin.

Mi opinión sobre Lombok es que simplemente proporciona accesos directos para escribir código clave en forma de bolígrafo.
Cuando se trata de usar accesos directos para escribir código clave en código fuente, confío en las características proporcionadas por IDE, como en Eclipse, podemos ir al menú Fuente> Generar captadores y definidores para generar captadores y definidores.
No confiaría en una biblioteca como Lombok para esto:

  1. Contamina el código con una capa indirecta de syntax alternativa (leer @Getter , @Setter , etc.). En lugar de aprender una syntax alternativa para Java, cambiaría a cualquier otro idioma que proporcione nativamente la syntax de Lombok.
  2. Lombok requiere el uso de un IDE compatible con Lombok para trabajar con su código. Esta dependencia introduce un riesgo considerable para cualquier proyecto no trivial. ¿El proyecto de código abierto Lombok tiene suficientes recursos para seguir brindando soporte para diferentes versiones de una amplia gama de IDE de Java disponibles?
  3. ¿El proyecto de código abierto Lombok tiene suficientes recursos para seguir brindando soporte para las versiones más nuevas de Java que vendrán en el futuro?
  4. También me preocupa que Lombok pueda presentar problemas de compatibilidad con frameworks / bibliotecas ampliamente utilizados (como Spring, Hibernate, Jackson, JUnit, Mockito) que funcionan con tu código de bytes en tiempo de ejecución.

En general, no preferiría “darle más sabor” a mi Java con Lombok.

No lo recomiendo Solía ​​usarlo, pero cuando trabajo con NetBeans 7.4 estaba estropeando mis códigos. Tengo que eliminar lombok en todos los archivos de mis proyectos. Hay delombok, pero ¿cómo puedo estar seguro de que no arruinaría mis códigos? Tengo que pasar días solo para eliminar lombok y volver a los estilos Java normales. Yo también muy picante …

Todavía no he intentado usar Lombok, está / estaba próximo en mi lista, pero parece que Java 8 le ha causado problemas importantes, y el trabajo de reparación todavía estaba en progreso desde hace una semana. Mi fuente para eso es https://code.google.com/p/projectlombok/issues/detail?id=451 .