Por fin luego de mucho luchar hemos hallado la contestación de este apuro que muchos lectores de esta web tienen. Si deseas aportar algún dato no dudes en aportar tu conocimiento.
Solución:
Recién comencé 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 definidores según los nombres de los campos. Si usa uno de esos captadores en otra clase, entonces decide que el campo tiene un nombre incorrecto, no encontrará usos de esos captadores y definidores y reemplazará el nombre antiguo por 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 durante 3 meses, todavía lo recomiendo para la mayoría de los proyectos. Sin embargo, encontré otro inconveniente similar al mencionado anteriormente.
Si tienes una clase, di MyCompoundObject.java que tiene 2 miembros, ambos anotados con @Delegate, decir myWidgets y myGadgets, cuando usted llama myCompoundObject.getThingies() de otra clase, es imposible saber si está delegando al Widget o Gadget porque ya no puede saltar a la fuente dentro del IDE.
El uso de “Generar métodos delegados …” de Eclipse le proporciona la misma funcionalidad, es igual de rápido y proporciona un salto de fuente. La desventaja es que abarrota su fuente con código repetitivo 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 resultar molesto en ocasiones 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 que superar 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:
- Falta de JavaDocs. Si hago javadoc en 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 complementos.
- 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 usar 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 quien llamagetDynamicCols(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. De hecho, puede establecer un punto de interrupción condicional (BP) en un método generado por Lombok. Utilizando el Outline ver, puede hacer clic con el botón derecho en el método para Toggle Method Breakpoint. Luego, cuando golpee el BP, puede usar la depuración Variables vista para ver cómo el método generado nombró los parámetros (generalmente el mismo que el nombre del campo) y finalmente, use el Breakpoints vista para hacer clic con el botón derecho en el 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 actualiza sus dependencias de Lombok en su pom de 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 la caché de Netbeans resuelve el problema. No estoy seguro de si hay una opción de “Proyecto limpio” como en Eclipse. Problema menor, pero quería darlo a conocer.
ACTUALIZACIÓN 5 (17 de enero de 2014)
Lombok no siempre juega bien con Groovy, o al menos el groovy-eclipse-compiler. Puede que tenga que 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 no lo use nunca.
ACTUALIZACIÓN 7 (23 de julio de 2014)
Esta es una actualización un poco interesante porque aborda directamente el la seguridad de adoptar Lombok sobre el que preguntó el OP.
A partir de la v1.14, el @Delegate la anotació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 utilizando esta función, sus opciones de cancelación son limitadas. Veo las opciones como:
- Quitar manualmente
@Delegateanotaciones y generar / codificar manualmente el código de delegado. Esto es un poco más difícil si estuvieras usando attributes dentro de la anotación. - Delombok los archivos que tienen el
@Delegateanotación y tal vez vuelva a agregar las anotaciones que desee. - Nunca actualice Lombok ni mantenga una bifurcación (o viva con el uso de funciones experimentales).
- Elimina 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 banderas de Delombok, pero no lo esperaría en un 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 cree que tendrá dificultades para vender la idea a los poderes fácticos, eche un vistazo a la @CompileStatic o @TypeChecked anotación para ver si eso puede ayudar a su causa. De hecho, el enfoque principal de la versión Groovy 2.0 fue static la seguridad.
ACTUALIZACIÓN 9 (1 de septiembre de 2015)
Lombok todavía se mantiene y mejora activamente, lo que es un buen augurio para el nivel de seguridad de adopción. Las anotaciones de @Builder son una de mis nuevas características favoritas.
ACTUALIZACIÓN 10 (17 de noviembre de 2015)
Esto puede no parecer directamente relacionado con la pregunta del PO, 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 observa su presentación de diapositivas, la lista de Lombok como una posible solución al problema que están tratando de resolver. Las desventajas que enumeran para Lombok son:
- El código insertado es invisible (no puede “ver” los métodos que genera) [ed note – actually you can, but it just requires a decompiler]
- Los hacks del compilador no son estándar y frágiles
- “En nuestra opinión, su código ya no es realmente Java”
No estoy seguro de si estoy de acuerdo con su evaluación. Y dados los contras 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 2016)
Descubrí que Spring Roo tiene algunas anotaciones similares. Me sorprendió un poco descubrir que Roo sigue existiendo y que encontrar documentación para las anotaciones es un poco complicado. La eliminación tampoco parece tan fácil como de-lombok. Lombok parece la opción más segura.
ACTUALIZACIÓN 12 (17 de febrero de 2016)
Mientras trataba 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 deshabilitar ciertas funciones que su equipo considere 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 2016)
Si este tipo de cosas le importa, Oliver Gierke sintió que era seguro agregar Lombok a Spring Data Rest.
ACTUALIZACIÓN 14 (26 de septiembre de 2017)
Como señaló @gavenkoa en los comentarios sobre la pregunta de OP, el soporte del compilador JDK9 aún no está disponible (Problema # 985). También parece que no será una solución fácil para el equipo de Lombok moverse.
ACTUALIZACIÓN 15 (26 de marzo de 2018)
El registro de cambios de Lombok indica a partir de la v1.16.20 “Ahora es posible compilar lombok en JDK1.9”, aunque # 985 todavía está abierto.
Los cambios para acomodar JDK9, sin embargo, requirieron algunos cambios importantes; todo aislado a los cambios en los valores predeterminados de configuración. Es un poco preocupante que hayan introducido 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 trataba sobre la seguridad, si tuvieras un yarn/npm como el sistema de compilación que se actualizó automáticamente a la última versión incremental, es posible que se encuentre en un rudo despertar.
ACTUALIZACIÓN 16 (9 de enero de 2019)
Parece que los problemas de JDK9 se han resuelto y Lombok funciona con JDK10, e incluso con JDK11, por lo que puedo decir.
Sin embargo, una cosa que noté que era preocupante desde el punto de vista de la seguridad es el hecho de que el registro de cambios que va de la v1.18.2 a la 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 los parches.
Parece que ya ha decidido que Project Lombok le brinda ventajas técnicas significativas 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 usar Project Lombok (o cualquier otra tecnología que cambie el juego) en algún proyecto (de código abierto o de otro modo), debe asegurarse de que las partes interesadas del proyecto estén de acuerdo con esto. Esto incluye a los desarrolladores y cualquier usuario importante (por ejemplo, patrocinadores formales o informales).
Mencionas estos posibles problemas:
Flamewars estallará en el canal ## Java Freenode cuando lo mencione,
Fácil. Ignore / no participe en las guerras de llamas, o simplemente absténgase de mencionar Lombok.
proporcionar fragmentos de código confundirá a los posibles ayudantes,
Si la estrategia del proyecto es utilizar Lombok, 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 el código fuente / reglas de documentación de su organización al software de código abierto de terceros. El equipo del proyecto debe tener la libertad de establecer estándares de documentación / código fuente del proyecto que sean apropiados para la tecnología que se esté utilizando.
(HACER UN SEGUIMIENTO – Los desarrolladores de Lombok reconocen que no generar comentarios javadoc para métodos getter y setter sintetizados es un problema. Si este es un problema importante para su (s) proyecto (s), entonces una alternativa es crear y enviar un parche de Lombok para solucionarlo).
y los futuros comprometidos podrían simplemente eliminarlo todo de todos modos.
¡Eso no está activado! Si la estrategia del proyecto acordada es utilizar Lombok, entonces se debería castigar a los autores de los compromisos que des-Lombok gratuitamente del código y, si es necesario, se les retirarán sus derechos de compromiso.
Por supuesto, esto supone que tiene la aceptación de las partes interesadas … incluidos los desarrolladores. Y asume que está preparado para defender su causa y manejar adecuadamente las inevitables voces disidentes.
Continúe y use Lombok, si es necesario, puede “delombok” su código después http://projectlombok.org/features/delombok.html
Si te sientes motivado, tienes la libertad de dejar una reseña acerca de qué te ha parecido este enunciado.