¿Cuáles son los riesgos con el Proyecto Lombok?

Question

Me vienen los objetivos de rendimiento para el nuevo año, y pensé que sería divertido poner un objetivo para reducir el tamaño de la base de código, especialmente repetitivo. Una acción que me he propuesto para solucionar esto es usar Project Lombok para hacer que los frijoles sean lo más pequeños posible. Pero tengo la costumbre de pasar por alto las desventajas del nuevo software y los enfoques, así que estoy confiando en la comunidad de Stack Overflow: ¿Alguien puede decirme por qué Lombok es una mala idea?

Answer 1

Una desventaja importante es la compatibilidad con IDE. Como Lombok no es en realidad un cambio de idioma, y ​​como su IDE solo entiende Java, necesitará un IDE que admita a Lombok para que las cosas funcionen correctamente. A partir de ahora, que es solo Eclipse que incluye Eclipse e IntelliJ. Si usa eclipse que podría estar bien, pero recuerde que también está tomando una decisión para futuros desarrolladores.

Le sugiero que considere mover algunos de sus códigos a un lenguaje menos ceremonial, como groovy. Hemos tenido éxito al mover algunos de nuestros modelos y lógica empresarial a groovy y funciona muy bien.

Answer 2

Una desventaja potencial para algo como Lombok es que con los setters/getters "perdidos", las herramientas de origen pueden no "reconocer" aspectos del objeto resultante que le dan cualidades de "frijol", ya que esas cualidades solo se manifiestan en el compilado clase.

Otra desventaja es que se trata de otra pieza de "magia negra" dentro de la cadena de herramientas. Afortunadamente, parece ser una pieza bastante benigna (no lo he usado), y el hecho de que suceda en tiempo de compilación en lugar de en tiempo de ejecución es realmente una bendición (en mi humilde opinión). Sin embargo, no podrá volver a utilizar o compartir su código sin el proyecto, ya que está agregando artefactos a su base de código. Entonces, aunque el archivo de clase compilado puede ser un "POJO", yo diría que su código fuente NO es un POJO.

Ninguno de estos son inconvenientes paralizantes, sino solo aspectos a tener en cuenta para mirar hacia adelante.

Answer 3

Una limitación de Lombok es el hecho de que está estrechamente relacionado con el compilador de Java. Dado que la API del procesador de anotaciones solo permite la creación de nuevos archivos durante la compilación (y no la modificación de los archivos existentes) lombok usa esa API como punto de entrada para modificar el compilador de Java. Desafortunadamente, estas modificaciones del compilador hacen un uso intensivo de API no públicas. Usar lombok puede ser una buena idea, pero debe tener en cuenta que actualizar su compilador puede romper su código. La probabilidad es baja, pero siempre me siento incómodo al usar API no públicas.

Answer 4

Como señaló el usuario @Jcs en otra respuesta, me gustaría agregar más.

En nuestro proyecto, estamos utilizando mapstruct que se utiliza para generar clases de asignador, antes de compilar el código, utilizando el comando mvn generate-sources, esto se hace en fase de proceso usando el complemento de procesador maven.

proyecto lombok agrega el bytecode para el getter/setter en el archivo de clase en la fase de compilación.

ya que la fase de proceso se ejecuta antes de la compilación, se encuentra que no hay getter/setter disponible en la clase.

Existen algunas soluciones disponibles para ejecutar la fase de compilación en más de una. Vea esto git hub ticket para más detalles.

Nota: estoy STS utilizando el IDE para la primavera y es apoyado por Lombok :)

Answer 5

Es una biblioteca de terceros, y hay desarrolladores que no se conocen bien.

IDE debe admitir el procesamiento de anotaciones (hay complementos para IDEA y Eclipse).

Como se mencionó anteriormente, su código será sin getters/setters. Conduce a violaciones de sonar/checkstyle.

Answer 6

En mi opinión, el código fuente en "Java + Lombok" ya no es el código fuente de Java. Lo veo como algo similar que hizo Borland hace muchos años en su Borland C++ Builder IDE para VCL: introdujeron "propiedades" en el código C++ introduciendo de hecho un tipo de lenguaje de programación nuevo que ya no era C++ (no C++ en el sentido de estándar de lenguaje C++). Las fuentes que usan "Java + Lombok" no son fuentes válidas en el sentido de la especificación del lenguaje Java. Además, creo que las anotaciones no fueron diseñadas para influir en la semántica del lenguaje.