Projet Lombok par rapport à des modèles Eclipse / génération de code

Question

projet Lombok offrent un avantage par rapport aux modèles de code / génération de code dans Eclipse? Y a-t-il des inconvénients (hormis y compris le .jar)?.

Answer 1

L'un des avantages de Lombok est qu'une fois que vous avez annoté une classe avec, par exemple, l'annotation @data, vous ne devez régénérer le code lorsque vous apportez des modifications. Par exemple, si vous ajoutez un nouveau champ, @data comprendrait automatiquement ce champ dans les égaux, les méthodes hashCode et toString. Vous auriez besoin de faire manuellement ce changement lors de l'utilisation des méthodes générées Eclipse. Une partie du temps, vous pouvez préférer le contrôle manuel mais pour la plupart des cas, je vous attendez pas.

Answer 2

L'avantage de Lombok est que le code est pas vraiment là -. À savoir les classes sont beaucoup plus lisibles et ne sont pas encombrées

Answer 3

Avantages:

• Très facile à utiliser

• Les classes sont beaucoup plus propre ( 'pas de code passe-partout'), en particulier « les classes internes en forme de struct' réduire à un strict minimum:

  @Data private class AttrValue { private String attribute; private MyType value; }

  Cela va créer deux accesseurs, un toString () et hachage correcte () / equals (), y compris les deux variables. La variante avec @Value crée une structure immuable (sans setters, tous les champs finaux).

• Pas besoin de générer / supprimer le code lorsque vous changez de champs (getter, setters, toString, hachage, est égal à)
• Aucune interférence avec les méthodes codées manuellement: simplement ajouter vos propres setter spécifiques à la classe en cas de besoin. Lombok et génère ce saute tout le reste

Inconvénients:

• Pas de refactoring nom, encore: renommer ci-dessus value ne sera pas (encore) renommer getValue() et setValue()
• Mai ralentit légèrement ecplise
• sortie toString pas aussi belle que, par exemple, ToStringBuilder de biens communs apache

Answer 4

Très peu viennent à l'esprit:

• il est basé sur l'annotation, donc pas bon pour le projet existant encore en pré-Java5 ( delombok peut aider). En fait, il faut l'aide du compilateur v1.6 javac.
• il encore des limites concernant plusieurs constructeurs

La question de la dépendance est à ne pas négliger cependant, mais vous avez exclue de votre question.

Answer 5

Eclipse EMF offre des fonctionnalités qui sont très pratiques qui Lombock ne supporte pas encore:

• notification puissant mechanims pour s'informer des changements dans vos instances
• API générique sans réflexion java. Accès et de rectification des instances sans une forte référence au type
• Commande API und édition basée sur
• Les références croisées entre les modèles: Créer et arbres modèles de charge et gère EMF le chargement en créant un proxy pour la référence croisée. Cela permet d'économiser les performances de la mémoire et de stimuler dans d'immenses arbres de domaine
• Et bien plus encore ...