sts plugin for java lombok

java - plugin - ¿Es seguro usar el Proyecto Lombok?



lombok plugin (15)

En caso de que no sepas, Project Lombok ayuda con algunas de las molestias de Java con cosas como generar getters y setters con anotaciones e incluso la generación simple de JavaBean con @Data . Realmente podría ayudarme, especialmente en 50 objetos de eventos diferentes en los que tiene hasta 7 campos diferentes que deben ser construidos y ocultos con captadores. Podría eliminar casi mil líneas de código con esto.

Sin embargo, me preocupa que a largo plazo, será una decisión lamentable. Flamewars estallará en el ##Java Freenode canal ##Java Freenode cuando lo mencione, siempre que los fragmentos de código confundan a los posibles ayudantes, la gente se quejará de la falta de JavaDoc y los futuros comentaristas podrían eliminarlos de todos modos. Realmente disfrutaría lo positivo, pero me preocupa lo negativo.

Entonces: ¿Es seguro usar Lombok en cualquier proyecto, pequeño o grande? ¿Valen los efectos positivos los negativos?

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

Si tiene una clase anotada con @Data , generará los captadores y configuradores para usted basándose en los nombres de los campos. Si utiliza uno de esos captadores en otra clase, luego decida que el campo tiene un nombre incorrecto, no encontrará los usos de esos captadores y definidores y reemplazará el nombre antiguo con el nombre nuevo.

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

ACTUALIZACIÓN (22 de enero de 13)
Después de usar Lombok durante 3 meses, todavía lo recomiendo para la mayoría de los proyectos. Sin embargo, encontré otro inconveniente que es similar al mencionado anteriormente.

Si tiene una clase, diga MyCompoundObject.java que tiene 2 miembros, ambos anotados con @Delegate , diga myWidgets y myGadgets , cuando llama a myCompoundObject.getThingies() de otra clase, es imposible saber si está delegando a un Widget o Gadget Porque ya no puedes saltar a la fuente dentro del IDE.

El uso de Eclipse "Generar métodos de delegado ..." le proporciona la misma funcionalidad, es igual de rápido y proporciona un salto de origen. La desventaja es que desordena su fuente con el código de la placa de la caldera que quita el foco de las cosas importantes.

ACTUALIZACIÓN 2 (26 de febrero de 2013)
Después de 5 meses, seguimos usando Lombok, pero tengo otras molestias. La falta de un getter y setter declarado puede ser molesto en momentos en que 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 que saltar para determinar el propósito de este método. Algunos de los obstáculos son Lombok, otros son la falta de un complemento inteligente de Lombok. Los obstáculos incluyen:

  • La falta de JavaDocs. Si hago javadoc el campo, espero que el captador y el colocador hereden ese javadoc a través del paso de compilación de Lombok.
  • Saltar 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 plugin
  • 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é al principio. Sin embargo, debe utilizar una perspectiva que habilite la vista Esquema. No es un problema para la mayoría de los desarrolladores. Mi problema fue que estaba usando Mylyn, que estaba filtrando mi vista de Outline , por lo que no vi los métodos. Búsqueda de falta de referencias. Si quiero ver quién llama a getDynamicCols(args...) , tengo que generar o codificar el configurador para poder buscar referencias.

ACTUALIZACIÓN 3 (7 de marzo de 13)
Aprendiendo 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 por Lombok. Usando la vista Outline , puede hacer clic con el botón derecho en el método para Toggle Method Breakpoint . Luego, cuando golpea el BP, puede usar la vista de Variables depuración para ver cómo el método generado denominó los parámetros (generalmente el mismo que el nombre del campo) y, finalmente, usar la vista de Breakpoints para hacer clic derecho en el BP y seleccionar Breakpoint Properties... para agregar una condicion Bonito.

ACTUALIZACIÓN 4 (16 de agosto de 13)
A Netbeans no le gusta que actualices tus dependencias de Lombok en tu pom Maven. El proyecto aún se compila, pero los archivos se marcan por errores de compilación porque no puede ver los métodos que está creando Lombok. Borrar el caché de Netbeans resuelve el problema. No estoy seguro si hay una opción de "Proyecto limpio" como la que hay en Eclipse. Tema 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 tenga que degradar su versión del compilador. Maven Groovy y Java + Lombok

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

ACTUALIZACIÓN 7 (23 de julio de 14)
Esta es una actualización bastante interesante, ya que aborda directamente la seguridad de adoptar Lombok que el OP preguntó.

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

La cosa es que, si estaba usando 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 delegado. Esto es un poco más difícil si estuviera usando atributos dentro de la anotación.
  • Delombok los archivos que tienen la anotación @Delegate y tal vez agregue de nuevo las anotaciones que desee.
  • Nunca actualice Lombok o mantenga un fork (o viva con el uso de características experienciales).
  • 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 ticket para solicitar esta función con las banderas de Delombok, pero no lo esperaría en un futuro próximo.

ACTUALIZACIÓN 8 (20 de octubre de 14)
Si es una opción para usted, Groovy ofrece la mayoría de los mismos beneficios de Lombok, además de una gran cantidad de otras características, incluida @Delegate . Si crees que te será difícil vender la idea a los poderes existentes, observa la anotación @CompileStatic o @TypeChecked para ver si eso puede ayudar a tu causa. De hecho, el enfoque principal de la versión Groovy 2.0 fue la seguridad estática .

ACTUALIZACIÓN 9 (1 de septiembre de 15)
Lombok todavía se mantiene y mejora activamente , lo que es un buen augurio para el nivel de seguridad de la adopción. Las anotaciones de @Builder son una de mis nuevas características 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 está buscando herramientas que lo ayuden a reducir la cantidad de código que usted escribe, también puede consultar Google Auto , en particular AutoValue . Si observa su plataforma de diapositivas , la lista de Lombok es una posible solución al problema que están tratando de resolver. Los contras que listan para Lombok son:

  • El código insertado es invisible (no puede "ver" los métodos que genera) [nota ed: en realidad puede, pero solo requiere un descompilador]
  • Los hacks del compilador no son estándar y frágiles.
  • "Desde nuestro punto de vista, su código ya no es realmente Java"

No estoy seguro de cuánto estoy de acuerdo con su evaluación. Y dadas las desventajas de AutoValue que se documentan en las diapositivas, me quedo con Lombok (si Groovy no es una opción).

ACTUALIZACIÓN 11 (8 de febrero de 16)
Descubrí que Spring Roo tiene algunas anotaciones similares . Me sorprendió un poco descubrir que Roo todavía es una cosa y encontrar documentación para las anotaciones es un poco difícil. 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 de 16)
Mientras intentaba encontrar justificaciones de por qué es seguro traer a Lombok para el proyecto en el que estoy trabajando, encontré una pieza de oro que se agregó con v1.14 : ¡El sistema de configuración ! Esto significa que puede configurar un proyecto para deshabilitar ciertas características que su equipo considera inseguras o indeseables. Mejor aún, también puede crear una configuración específica de directorio con diferentes configuraciones. Esto es impresionante.

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

ACTUALIZACIÓN 14 (26 de septiembre de 17)
Como lo señaló gavenkoa en los comentarios sobre la pregunta de los OP, el soporte del compilador JDK9 aún no está disponible (Número de problema 985). También parece que no va a ser una solución fácil para que el equipo de Lombok se mueva.

ACTUALIZACIÓN 15 (26 de marzo de 18)
El registro de cambios de Lombok indica a partir de la v1.16.20 " Compilar lombok en JDK1.9 ahora es posible " aunque # 985 aún está abierto.

Los cambios para acomodar JDK9, sin embargo, necesitaron algunos cambios de ruptura; Todos aislados a 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" (que va de v1.16.18 a v1.16.20). Ya que esta publicación fue sobre la seguridad, si tenía un sistema de yarn/npm como compilación que se actualizó automáticamente a la última versión incremental, es posible que tenga un mal despertar.

Cuando le mostré el proyecto a mi equipo, el entusiasmo era alto, así que creo que no debes tener miedo de la respuesta del equipo.

  • En cuanto al ROI, es fácil de integrar y no requiere ningún cambio de código en su forma básica. (solo añadiendo una sola anotación a tu clase)

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

He encontrado un problema con Lombok y Jackson CSV , cuando complacía mi objeto (java bean) en un archivo CSV, las columnas estaban duplicadas, luego eliminé la anotación @Data de Lombok y la recualización funcionó bien.

He usado Lombok en casi todos mis proyectos durante un año, pero desafortunadamente lo eliminé. Al principio, era una forma muy limpia de desarrollo, pero configurar 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 quité. Pero es un buen trabajo y necesita algo más de simplicidad para configurarlo.

Leí algunas opiniones sobre el Lombok y en realidad lo estoy usando en algunos proyectos.

Bueno, en el primer contacto con Lombok tuve una mala impresión. Después de algunas semanas, me empezó a gustar. 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:

  • Dependencia del complemento IDE . El soporte IDE para Lombok es a través de complementos. Incluso trabajando bien la mayor parte del tiempo, siempre eres un rehén de estos complementos que se mantendrá en las futuras versiones de los IDE e incluso el lenguaje (Java 10+ acelerará el desarrollo del lenguaje). Por ejemplo, traté de actualizar desde Intellij IDE 2017.3 a 2018.1 y no pude hacerlo porque hay un problema en la versión real del plugin de lombok y necesito esperar a que se actualice el plugin ... Esto también es un problema si quisiera usar un IDE más alternativo que no tenga soporte para el complemento Lombok.
  • Problema ''encontrar usos''. . Si utiliza Lombok, no verá los métodos generadores, definidores, constructores, constructores, etc. generados. Por lo tanto, si planea averiguar qué métodos está utilizando su proyecto en su proyecto, no puede hacer esto solamente. Buscando la clase que posee estos métodos ocultos.
  • 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. Entonces, muchas veces simplemente copian y @Getter @Setter @Builder @AllArgsConstructor @NoArgsConstructor sin pensar qué métodos realmente necesita exponer la clase.
  • Constructor Obssession ©. Inventé este nombre (baje, Martin Fowler). Aparte de las bromas, un Builder es tan fácil de crear que incluso cuando una clase tiene solo dos parámetros, los desarrolladores prefieren usar @Builder lugar del constructor o un método constructor estático. A veces incluso intentan crear un Builder dentro del lombok Builder, creando situaciones extrañas como MyClass.builder().name("Name").build().create() .
  • Barreras a la hora de refactorizar . Si está utilizando, por ejemplo, un @AllArgsConstructor y necesita agregar un parámetro más en el constructor, el IDE no puede ayudarlo a agregar este parámetro adicional en todos los lugares (en su mayoría, pruebas) que crean una instancia de la clase.
  • Mezclar 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 te sientes como un hack en el idioma.

Como dijo otra respuesta, si estás enojado por la verbosidad de Java y usas Lombok para tratar con eso, prueba con Kotlin.

Lombok es genial, pero ...

Lombok rompe las reglas de procesamiento de anotaciones, ya que no genera nuevos archivos de origen. Esto significa que no se puede usar con otros procesadores de anotación si esperan que los captadores / definidores o cualquier otra cosa exista.

El procesamiento de anotaciones 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 manera, 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 se basan en el código lombok no se ejecutan como se esperaba. Esta fue una gran fuente de dolor para mí al usar mapstruct, y el borrado de llamadas no es una opción útil, ya que destruye los números de línea en los registros.

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

Mi opinión sobre Lombok es que simplemente proporciona accesos directos para escribir código Java de boliler.
Cuando se trata de usar accesos directos para escribir código Java de placa de control, confiaría en las características proporcionadas por IDE, como en Eclipse, podemos ir al menú Fuente> Generar generadores y definidores para generar generadores y definidores.
No confiaría en una biblioteca como Lombok para esto:

  1. Contamina su código con una capa de indirección de sintaxis alternativa (lea las @Getter , @Setter , etc.). En lugar de aprender una sintaxis alternativa para Java, cambiaría a cualquier otro lenguaje que proporcione de forma nativa la sintaxis 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 recursos suficientes 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 recursos suficientes para seguir brindando soporte para las versiones más recientes de Java que vendrán en el futuro?
  4. También me siento nervioso de que Lombok pueda presentar problemas de compatibilidad con los marcos / bibliotecas ampliamente utilizados (como Spring, Hibernate, Jackson, JUnit, Mockito) que funcionan con su código de bytes en el tiempo de ejecución.

En general, no preferiría "condimentar" mi Java con Lombok.

No lo recomiendo. Solía ​​usarlo, pero luego cuando trabajo con NetBeans 7.4 estaba desordenando mis códigos. Tengo que eliminar lombok en todos los archivos en mis proyectos. Hay delombok, pero ¿cómo puedo estar seguro de que no atascaría mis códigos? Tengo que pasar días solo para eliminar lombok y volver a los estilos normales de Java. Simplemente demasiado picante ...

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 una opinión particular sobre el Proyecto Lombok, de una forma u otra).

Antes de usar 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 los interesados ​​en el proyecto estén de acuerdo con esto. Esto incluye a los desarrolladores y a cualquier usuario importante (por ejemplo, patrocinadores formales o informales).

Usted menciona estos problemas potenciales:

Flamewars estallará en el ## canal Java Freenode cuando lo mencione,

Fácil. Ignore / no participe en los flamewars, o simplemente absténgase de mencionar a Lombok.

proporcionar fragmentos de código confundirá posibles ayudantes,

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

la gente se quejará de perder 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 código abierto de terceros. El equipo del proyecto debe tener la libertad de establecer el código fuente / estándares de documentación del proyecto que sean apropiados para la tecnología que se está utilizando.

( SEGUIMIENTO : los desarrolladores de Lombok reconocen que no generar comentarios de javadoc para los métodos de obtención y configuración sintetizados es un problema. Si este es un problema importante para su (s) proyecto (s), una alternativa es crear y enviar un parche de Lombok para solucionarlo. )

y los futuros comentaristas podrían eliminar todo de todos modos.

¡Eso no está encendido! Si la estrategia del proyecto acordada es utilizar Lombok, entonces los comisionados que de forma gratuita eliminan el código de Lombok deben ser castigados y, si es necesario, se les debe retirar sus derechos de compromiso.

Por supuesto, esto supone que hay un compromiso por parte de los interesados ​​... incluidos los desarrolladores. Y asume que estás preparado para argumentar tu causa y manejar adecuadamente las inevitables voces disidentes.

Personalmente (y, por lo tanto, subjetivamente), descubrí que el uso de Lombok hace que mi código sea más expresivo acerca de lo que estoy tratando de lograr cuando se compara con IDE / implementaciones propias de métodos complejos como hashcode y iguales.

Cuando usas

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

es mucho más fácil mantener Equals & HashCode coherente y realizar un seguimiento de qué campos se evalúan, que cualquier IDE / propia implementación. Esto es especialmente cierto cuando todavía estás agregando / eliminando 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 al campo y ya sea para llamar a super.toString() .

Y nuevamente, al anotar una clase completa con @Getter o @Setter(AccessLevel.NONE) (y, opcionalmente, anular cualquier método divergente) queda claro de inmediato 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 descifrarlo desde Javadoc o implementaciones. El código reducido solo facilita la detección de implementaciones de métodos divergentes.

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

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

Tuvo que copiar manualmente los métodos generados desde el origen delimitado y poner lombok en espera hasta mejores tiempos.

Actualizar

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

Se archivó un problema: https://github.com/rzwitserloot/lombok/issues/648

Actualizar

mplushnikov comentó el 30 de enero de 2016:

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

Actualizar

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

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.

Sobre tu pregunta: definitivamente es más fácil que tus desarrolladores prueben Lombok que a Scala. Pruébalo y si les gusta, prueba Scala.

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

También hay riesgos de mantenimiento a largo plazo. Primero, recomiendo leer sobre cómo funciona realmente Lombok, por ejemplo, algunas respuestas de sus desarrolladores here .

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

Es un hack total. Utilizando API no pública. Reparto presuntuoso (sabiendo que un procesador de anotaciones que se ejecuta en javac obtendrá una instancia de JavacAnnotationProcessor, que es la implementación interna de AnnotationProcessor (una interfaz), que por lo tanto tiene un par de métodos adicionales que se utilizan para obtener AST en vivo) .

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

Si pudieras hacer lo que hace lombok con la API estándar, lo habría hecho así, pero no puedes. Aún así, por lo que valía, 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 que también se ejecuta en java 1.5, por lo que no es completamente frágil.

Como resumen, si bien 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 la vulnerabilidad), Lombok podría quedar atrapado en una versión antigua de Java mientras que los desarrolladores se apresuran a actualizar su uso. API internas. Si esto es un riesgo grave, obviamente depende del proyecto.