¿Es seguro usar Project Lombok? [cerrado]

436

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

Sin embargo, me preocupa que a la larga sea una decisión lamentable. Flamewars entrará en erupción en el ##Java Freenodecanal cuando lo mencione, proporcionar fragmentos de código confundirá a los posibles ayudantes, la gente se quejará de la falta de JavaDoc y los futuros comisionados podrían eliminarlo 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? ¿Los efectos positivos valen los negativos?

TheLQ
fuente
55
Agregar el soporte del compilador jdk9 # 985 no está resuelto al momento de mi comentario. El sistema de paquetes de Java 9 requiere agregar muchas opciones de CLI javacpara abrir el acceso a las sun.*clases internas ((
gavenkoa
1
Quizás interesante: medium.com/@gabor.liptak/…
Gábor Lipták
En estos días, los proyectos utilizan el preprocesador de anotaciones integrado en javac para hacer cosas como esta: este mecanismo es estándar y se puede esperar que los buenos programadores lo sepan.
Thorbjørn Ravn Andersen

Respuestas:

182

Parece que ya ha decidido que el Proyecto Lombok le brinda importantes ventajas técnicas para su nuevo proyecto propuesto. (Para ser claros desde el principio, no tengo puntos de vista particulares 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 u otro), debe asegurarse de que los interesados ​​en el proyecto estén de acuerdo con esto. Esto incluye a los desarrolladores y cualquier usuario importante (por ejemplo, patrocinadores formales o informales).

Usted menciona estos posibles problemas:

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

Fácil. Ignora / no participes en los flamewars, o simplemente abstente de mencionar a Lombok.

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

Si la estrategia del proyecto es utilizar 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 código abierto de terceros. El equipo del proyecto debe ser libre 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 sintetizadores getter y setter es un problema. Si este es un problema importante para sus proyectos, entonces una alternativa es crear y enviar un parche de Lombok para solucionarlo. )

y los futuros comisionados podrían eliminarlo de todos modos.

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

Por supuesto, esto supone que tiene el compromiso de las partes interesadas ... incluidos los desarrolladores. Y supone que está preparado para discutir su causa y manejar adecuadamente las inevitables voces disidentes.

Stephen C
fuente
77
Como desarrollador de Lombok, puedo decir que generar javadoc es técnicamente posible. Participe en el grupo de Google si tiene ideas brillantes sobre cómo implementarlo. Quiero decir, solo generar un texto estándar no es tan útil. Al igual que getFoo, devuelve foo, setFoo establece el foo? ¿Cómo va a ayudar eso?
Roel Spilker
177
Yo diría que javadoc para captadores / creadores de frijoles hace más daño que bien. Esos métodos siguen una convención bien entendida que no necesita agregarse al javadoc; eso solo se suma al ruido. Solo agregue documentación a los captadores y establecedores cuando hacen algo inesperado, es decir, cuando tienen efectos secundarios.
GaryF
99
Me acabo de dar cuenta de que el comentario de javadoc podría referirse al hecho de que si generas javadoc para tu código lomboked, los captadores y los setters no aparecen en absoluto. La forma de solucionarlo es ejecutar javadoc sobre su código delomboked.
Roel Spilker
14
@GaryF ¿En serio? ¿Qué tal documentar si el valor puede ser nulo? ¿O el rango permitido para un valor numérico? ¿O la longitud permitida y / o el formato de un valor de cadena? ¿O si un valor de cadena es adecuado para presentarlo a un usuario final? ¿O documentar lo que realmente significa la propiedad, cuando su nombre no puede explicarlo en su totalidad? ( JList.getLayoutOrientation y JList.setLayoutOrientation vienen a la mente.)
VGR
21
@VGR Estoy de acuerdo con lo que dices en general, pero una mejor solución en ese caso específico es un mejor nombre, no comentarios. es decir getCreationDate, getDueDate. Nombrar triunfos comentarios donde sea posible.
GaryF
850

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

Si tiene una clase anotada con @Data, generará los captadores y establecedores para usted en función de los nombres de campo. Si usa uno de esos captadores en otra clase, luego decida que el campo tiene un nombre incorrecto, no encontrará usos de esos captadores y establecedores y reemplazará el nombre antiguo con el nuevo nombre.

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, digamos MyCompoundObject.javaque tiene 2 miembros, ambos anotados con @Delegate, digamos myWidgetsy myGadgets, cuando llama myCompoundObject.getThingies()desde otra clase, es imposible saber si está delegando al Widgeto Gadgetporque ya no puede saltar a la fuente dentro del IDE.

Usar el "Generar métodos de delegado ..." de Eclipse le proporciona la misma funcionalidad, es igual de rápido y proporciona un salto de origen. La desventaja es que satura tu fuente con código repetitivo que quita el foco de las cosas importantes.

ACTUALIZACIÓN 2 (26 de febrero de 13)
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 intentas familiarizarte con el nuevo código.

Por ejemplo, si veo un método llamado getDynamicCols()pero no sé de qué se trata, tengo que superar algunos obstáculos adicionales 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 javadoc el campo, espero que el getter y setter 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 captador. Este es un problema de complemento.
  • Obviamente, no puede establecer un punto de interrupción en un captador / definidor a menos que genere o codifique el método.
  • NOTA: Esta búsqueda de referencia no es un problema como pensé por primera vez. Sin embargo, debe utilizar una perspectiva que habilite la vista Esquema. No es un problema para la mayoría de los desarrolladores. Mi problema era que estaba usando Mylyn, que estaba filtrando mi Outlinevista, por lo que no vi los métodos. 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 13)
Supongo que aprender a usar las diversas formas de hacer las cosas en Eclipse. En realidad, puede establecer un punto de interrupción condicional (BP) en un método generado por Lombok. Con la Outlinevista, puede hacer clic con el botón derecho en el método Toggle Method Breakpoint. Luego, cuando golpee el BP, puede usar la Variablesvista de depuración para ver cómo el método generado nombró los parámetros (generalmente el mismo que el nombre del campo) y finalmente, usar la Breakpointsvista para hacer clic derecho en el BP y seleccionar Breakpoint Properties...para agregar una condición. Agradable.

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

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

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

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

La cuestión es que, si estaba usando esta función, sus opciones de retroceso son limitadas. Veo las opciones como:

  • Elimine manualmente las @Delegateanotaciones y genere / codifique manualmente el código delegado. Esto es un poco más difícil si estaba utilizando atributos dentro de la anotación.
  • Elimine los archivos que tienen la @Delegateanotación y quizás vuelva a agregar las anotaciones que desee.
  • Nunca actualice Lombok ni mantenga una bifurcación (ni viva utilizando funciones experimentales).
  • Delombok todo su proyecto y deje 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 esperaría eso en el futuro cercano.

ACTUALIZACIÓN 8 (20 de octubre de 2014)
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, incluido @Delegate . Si usted cree que tendrá dificultades para vender la idea a los poderes fácticos, echar un vistazo a la @CompileStatico @TypeCheckedanotación para ver si eso puede ayudar a su 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 2015)
Lombok aún 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 funciones favoritas.

ACTUALIZACIÓN 10 (17 de noviembre de 2015)
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 repetitivo que escribe, también puede consultar Google Auto , en particular AutoValue . Si nos fijamos en su plataforma de diapositivas , la lista de 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 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 son frágiles.
  • "En nuestra opinión, su código ya no es realmente Java"

No estoy seguro de cuánto estoy de acuerdo con su evaluación. Y dados 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 de 16)
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 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 trataba de encontrar justificaciones de por qué es seguro traer a 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 deshabilitar ciertas funciones 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 de 16)
Si este tipo de cosas son importantes para usted, 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 los OP, el soporte del compilador JDK9 aún no está disponible (Número 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 " Compilar lombok en JDK1.9 ahora es posible " a pesar de que el # 985 todavía está abierto.

Sin embargo, los cambios para acomodar JDK9 requirieron algunos cambios importantes; todo aislado a los cambios en los valores predeterminados de configuración. Es un poco preocupante que introdujeron cambios importantes, pero la versión solo superó el número de versión "Incremental" (pasando de v1.16.18 a v1.16.20). Dado que esta publicación fue sobre la seguridad, si tuviera un yarn/npmsistema de compilación similar que se actualizara automáticamente a la última versión incremental, es posible que se encuentre con un rudo despertar.

ACTUALIZACIÓN 16 (9 de enero de 19)

Parece que los problemas de JDK9 se han resuelto y Lombok funciona con JDK10, e incluso JDK11 hasta donde puedo decir.

Sin embargo, una cosa que noté que era preocupante por un aspecto de seguridad es el hecho de que el registro de cambios que va de v1.18.2 a v1.18.4 enumera dos elementos como BREAKING CHANGE! No estoy seguro de cómo ocurre un cambio importante en una actualización de "parche" de semver. Podría ser un problema si usa una herramienta que actualiza automáticamente las versiones de parches.

Snekse
fuente
49
Gracias Creo que esta fue la información que el OP realmente quería en lugar de una respuesta filosófica.
chaostheory
14
UPDATE 6se siente mucho como Scala :)
mauhiz
55
@mauhiz y Groovy. Si alguna vez tuviera que trabajar en un lugar donde no pudiera usar Groovy o Scala al menos para las pruebas, probablemente lo dejaría en poco tiempo.
Snekse
8
Realmente me gustan sus actualizaciones con el tiempo de respuesta de estilo. Particularmente para una pregunta / respuesta de este estilo realmente ayuda.
MattG
44
Parece que el soporte de Java 9 ya está disponible. Puedes actualizar tu respuesta. stackoverflow.com/questions/41520511/…
leventunver
115

Siga adelante y use Lombok, puede, si es necesario, "delombok" su código después http://projectlombok.org/features/delombok.html

Kennet
fuente
55
@fastcodejava cuando dices "+1 para x", x debería ser uno de los puntos enumerados, no el único punto :)
Kerem Baydoğan
77
En esta situación particular, interpreté "+1 para delombok" como "larga vida delombok". Me gusta.
Zoltán
1
"+1 para delombok": especialmente cierto cuando desea utilizar lombok en proyectos que se proporcionarán a sus clientes. Puede aprovechar todas las ventajas de lombok y dejar que sus clientes vean un frasco limpio sin dependencia de lombok.
fwonce
Para las personas que piensan "está bien, intentaré a Lombok, y si no me gusta simplemente voy a Delombok": piénselo dos veces. Ejecutar Delombok es un proceso doloroso. Y el código resultante funcionará como lo hizo con Lombok ... pero también será un completo desastre.
AJPerez
75

Personalmente (y por lo tanto subjetivamente) descubrí que el uso de Lombok hace que mi código sea más expresivo sobre lo que estoy tratando de lograr en comparación con las implementaciones IDE / propias de métodos complejos como hashcode & equals.

Cuando usas

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

es mucho más fácil mantener la coherencia de Equals & HashCode y realizar un seguimiento de los campos evaluados que cualquier implementación IDE / propia. Esto es especialmente cierto cuando todavía está agregando / eliminando campos regularmente.

Lo mismo ocurre con la @ToStringanotación 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 si se debe llamar o no super.toString().

Y nuevamente, al anotar una clase completa con @Gettero @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 resolverlo a partir de Javadoc o implementaciones. El código reducido hace que sea más fácil detectar implementaciones de métodos divergentes.

Tim
fuente
21
Y para agregar a esto: cambiar a Lombok realmente ha permitido resolver algunos errores intrincados en el pasado debido a implementaciones de igual / hashCode no coincidentes, y casos en los que olvidé actualizar los métodos generados ahora cuando se agregó un campo. Estos beneficios potenciales deberían poder equilibrar la mayoría de los aspectos negativos que ha mencionado.
Tim
25

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 existan getters / setters o cualquier otra cosa.

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 anotaciones no importa si solo generan nuevos archivos. Como lombok no genera ningún archivo nuevo, no se inician nuevas rondas, por lo que algunos AP que se basan en el código de lombok no se ejecutan como se esperaba. Esto fue una gran fuente de dolor para mí al usar Mapstruct, y la eliminación de la fusión no es una opción útil, ya que destruye los números de línea en los registros.

Eventualmente pirateé un script de compilación para trabajar con lombok y mapstruct. Pero quiero abandonar lombok debido a lo hacky que es, al menos en este proyecto. Yo uso lombok todo el tiempo en otras cosas.

Twentylemon
fuente
22

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 descubrí 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 en la mayor parte del tiempo, siempre eres un rehén de estos complementos que se mantendrán en futuras versiones de los IDE e incluso en la versión del idioma (Java 10+ acelerará el desarrollo del lenguaje). Por ejemplo, intenté actualizar de Intellij IDEA 2017.3 a 2018.1 y no pude hacerlo porque había algún problema en la versión real del complemento lombok y necesitaba esperar a que se actualizara el complemento ... Esto también es un problema si usted quisiera usar un IDE más alternativo que no tenga soporte para el complemento Lombok.
  • Problema de 'Encontrar usos'. . Al usar Lombok, no ve los métodos getter, setter, constructor, constructor, etc. para 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 de los desarrolladores a no controlar más qué métodos deben ser visibles o no. Entonces, muchas veces solo están copiando y pegando @Getter @Setter @Builder @AllArgsConstructor @NoArgsConstructorbloques de anotaciones sin pensar en qué métodos la clase realmente necesita exponerse.
  • Constructor Obsesession ©. Inventé este nombre (baja, Martin Fowler). Bromas aparte, un Builder es tan fácil de crear que incluso cuando una clase tiene solo dos parámetros que los desarrolladores prefieren usar en @Builderlugar de un constructor o un método de constructor estático. A veces incluso intentan crear un generador dentro del generador de lombok, creando situaciones extrañas como MyClass.builder().name("Name").build().create().
  • Barreras al refactorizar . Si está utilizando, por ejemplo, ay @AllArgsConstructornecesita agregar un parámetro más en el constructor, el IDE no puede ayudarlo a agregar este parámetro adicional en todos los lugares (principalmente, pruebas) que están instanciando la clase.
  • Mezclando Lombok con métodos concretos . No puede usar Lombok en todos los escenarios para crear un captador / configurador / etc. Entonces, verá estos dos enfoques mezclados en su 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 lidiar con eso, prueba Kotlin.

Dherik
fuente
8
Yo diría que vaya por Kotlin o quédese con Java simple. Puede pasar más tiempo revisando los problemas de Lombok de los que ahorra al no escribir el código de Java.
jediz
1
Quien odie a Java solo por la verbosidad es su culpa por no hacer que su código sea menos detallado ...
Nikolas
17

También existen riesgos de mantenimiento a largo plazo. Primero, recomendaría leer sobre cómo funciona realmente 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. Utilizando API no pública. Conversión presuntuosa (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 utilizan para acceder al AST en vivo) .

En eclipse, podría decirse que es peor (y aún más robusto): se usa un agente de Java 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 la API estándar, lo habría hecho de esa manera, pero no puedes. Aún así, para lo que vale, desarrollé el complemento eclipse para eclipse v3.5 que se ejecuta en java 1.6, y sin hacer 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.

En resumen, si bien Lombok puede ahorrarle algo de tiempo de desarrollo, si hay una actualización de javac no compatible con versiones anteriores (por ejemplo, una mitigación de vulnerabilidad), Lombok podría quedarse con una versión anterior de Java mientras los desarrolladores se esfuerzan por actualizar su uso de esos API internas. Si esto es un riesgo grave obviamente depende del proyecto.

dskrvk
fuente
8
Bueno, en caso de que ya no pueda usar Lombok, simplemente ejecute delombok y continúe el desarrollo sin él.
vladich
3
Esto es como aprender a conducir usando anteojos y luego perderlos antes del examen de manejo. Si su equipo está acostumbrado a trabajar con el código de Lombok y de repente se ve obligado a cambiar su proceso debido a un cambio importante, eso tendrá un gran impacto en los proyectos en curso. ¿No es mejor evitar este riesgo por completo y usar un marco que no se base en características indocumentadas o un lenguaje como Scala que proporcione las mismas características listas para usar?
dskrvk
15

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

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

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

sorencito
fuente
Me gustan Scala y Lombok, pero no puedo ver de qué ideas estás hablando. \ @SneakyThrows, \ @Data, ...?
sinuhepop
2
@sinuhepop Generar captadores y establecedores se parece a las clases de casos. La característica inmutable es inherente a Scala y las API enriquecedoras sobre sus propios métodos también están integradas en Scala.
sorencito
55
pruebe Kotlin también
jediz
15

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

vici
fuente
27
¿Puedes dar más detalles sobre los dolores de cabeza?
Kevin Welker
2
La configuración de Eclipse es extremadamente sencilla. Solo "java -jar lombok.jar".
14
Creo que la parte más difícil de configurar un nuevo desarrollador es darse cuenta de que necesita configurar Lombok. No hay ningún mensaje que diga "Lombok no se ha configurado" ni nada de eso. En su lugar, obtienes mensajes extraños como "setFoo" no está definido. Si la educación de Lombok no es parte de su nuevo proceso de capacitación a bordo para desarrolladores, habrá una gran confusión.
Snekse
@Snekse. No sé exactamente qué versión del complemento lombok introdujo la notificación y sugerencia de idea inteligente (aparece un mensaje rojo y una sugerencia en el registro de errores para instar al usuario a habilitar la anotación e incluso proporcionó el enlace a la sección de configuración), pero Idea 2016.3 y la versión del complemento 0.13.16 contiene contiene este útil soporte.
jtonic
2
El complemento de idea de lombok (uso la versión 0.13.16) recientemente introdujo el soporte para notificar al usuario que el procesador de anotaciones no estaba configurado y también proporciona un enlace a la sección de configuración de configuración para habilitar el apt. Por favor, vea la captura de pantalla en. postimg.org/image/5tm2zzvkh
jtonic
11

Cuando le mostré el proyecto a mi equipo, el entusiasmo era alto, así que creo que no debes temer 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 agrega una anotación a tu clase)

  • Y por último, si cambia de opinión, puede ejecutar el unlombok o dejar que su IDE cree estos iniciadores, captadores y controladores (lo que creo que nadie solicitará una vez que vean cuán claro se vuelve su pojo)

Dov Tsal S
fuente
10

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

  1. Contamina su código con una capa indirecta de sintaxis alternativa (lea @Getter,@Setter etc. anotaciones). En lugar de aprender una sintaxis alternativa para Java, cambiaría a cualquier otro lenguaje que proporcione de forma nativa la sintaxis similar a 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 nuevas versiones de Java que vendrán en el futuro?
  4. También estoy nervioso de que Lombok pueda introducir problemas de compatibilidad con frameworks / bibliotecas ampliamente utilizados (como Spring, Hibernate, Jackson, JUnit, Mockito) que funcionan con su código de bytes en tiempo de ejecución.

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

Sanjeev Sachdev
fuente
Un argumento contrario a esto sería: ¿qué pasaría si alguien usara IDE para construir toda la placa de refuerzo de un POJO, pero luego uno de los captadores / establecedores fue renombrado o eliminado? La clase ya no es un POJO estricto, pero esto debe inferirse de una inspección cuidadosa de todos los métodos de la clase. Encuentro que las anotaciones de lombok al menos evitan esto y hacen que la lógica comercial de mis clases sea mucho más destacada. Todos tus puntos son válidos; Sin embargo, solo quería ofrecer este pensamiento. Y lombok lleva esto más lejos con @ Data / @ Value / @ Utility / @ Builder
Adam Hughes
10

Quería usar lombok's @ToStringpero pronto enfrentó errores de compilación aleatorios en la reconstrucción del proyecto en Intellij IDEA. Tuve que presionar la compilación varias veces antes de que la compilació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 complemento de lombok en jdk 1.6.0_39 y 1.6.0_45.

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

Actualizar

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

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

Actualizar

mplushnikov comentó el 30 ene 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.

Vadzim
fuente
6

Me he encontrado con un problema con Lombok y Jackson CSV , cuando clasifiqué 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.

Gugelhupf
fuente
2

No lo recomiendo Solía ​​usarlo, pero luego, cuando trabajo con NetBeans 7.4, estaba confundiendo 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 estropeará mis códigos? Tengo que pasar días solo para eliminar lombok y volver a los estilos Java normales. Yo demasiado picante ...

Harun
fuente
Entonces, ¿qué me recomiendan para anotar JavaBeans?
IgorGanapolsky
El equipo de lombok ha actualizado su código. Aún así, tengo que esperar varios meses antes de que esté listo
Harun
0

Todavía no he intentado usar Lombok: es / fue el siguiente en mi lista, pero parece que Java 8 le ha causado problemas importantes, y el trabajo de recuperació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 .

ChrisA
fuente
Solo para que conste, ese problema se migró a github.com/rzwitserloot/lombok/issues/524
seanf el
1
No tengo ningún problema con lombok en Java 8
Alexey
Estuve trabajando con lombok durante meses y funciona bien con Java 8. El proyecto en el que estoy trabajando ya usa lombok durante años y hasta ahora no se han encontrado problemas.
kevenlolo