¿Ofrece Project Lombok algún beneficio en comparación con las plantillas de código/generación de código en Eclipse? ¿Hay algún inconveniente (aparte de incluir el .jar) ?.Proyecto Lombok vs. Eclipse plantillas/generación de código
Una ventaja de Lombok es que una vez que ha anotado una clase con, por ejemplo, la anotación @Data, nunca necesita regenerar el código cuando realiza cambios. Por ejemplo, si agrega un nuevo campo, @Data incluiría automáticamente ese campo en los métodos equals, hashCode y toString. Tendrá que hacer ese cambio manualmente cuando use los métodos generados por Eclipse. Algunas veces, es posible que prefiera el control manual pero, en la mayoría de los casos, espero que no.
Muy pocos vienen a la mente:
La cuestión de la dependencia no debe pasarse por alto, sin embargo, pero se han excluido de su pregunta.
La ventaja de Lombok es que el código no está realmente allí, es decir, las clases son mucho más legibles y no están desordenadas.
Si el código no está allí, ¿cómo se compila en eclipse? – javaguy
@javaguy - se conecta al compilador, por lo que recuerdo. – Bozho
@javaguy El código está 'allí' en el archivo .class (generado por lombok), 'no está allí' como texto en su archivo .java, eliminando así gran cantidad de placa de caldera y desorden. – Ivin
Ventajas:
clases son mucho más limpia ('sin código repetitivo'), especialmente 'struct'-como las clases internas reducir al mínimo:
@Data private class AttrValue { private String attribute; private MyType value; }
Esto creará getters y setters, un toString() y métodos hash()/equals() correctos que incluyen ambas variables. La variante con @Value crea una estructura inmutable (sin setters, todos los campos son definitivos).
Desventajas:
value anterior no (todavía) renombrar getValue() y setValue()toString salida no tan agradable como, por ejemplo, ToStringBuilder de apache commonsEclipse EMF ofrece algunas características que son muy práctico, que Lombock todavía no soporta:
En la actualidad, la única necesidad de tiempo de ejecución para el frasco es si utiliza @SneakyThrows. Para todas las otras funciones, solo necesita el jar en tiempo de compilación. –
Se parece mucho a SpringRoo pero es mucho más simple. –