Quels sont les risques du projet Lombok ?

Question

Je suis en train de définir des objectifs de performance pour la nouvelle année, et j'ai pensé qu'il serait amusant de mettre un objectif visant à réduire la taille de la base de code, en particulier le boilerplate. Une action que j'ai trouvée pour y remédier est l'utilisation de Projet Lombok pour rendre les haricots aussi courts qu'ils devraient l'être. Mais j'ai l'habitude de négliger les inconvénients des nouveaux logiciels et des nouvelles approches, alors je m'en remets à la communauté Stack Overflow : Quelqu'un peut-il me dire pourquoi Lombok est une mauvaise idée ?

Answer 1

Une limitation de Lombok est le fait qu'il est étroitement lié au compilateur java. Comme l'API du processeur d'annotations ne permet que la création de nouveaux fichiers pendant la compilation (et non la modification des fichiers existants), Lombok utilise cette API comme point d'entrée pour modifier le compilateur java. Malheureusement, ces modifications du compilateur font un usage intensif d'APIs non publiques. Utiliser lombok peut être une bonne idée mais vous devez être conscient que la mise à jour de votre compilateur peut casser votre code. La probabilité est faible mais je me sens toujours mal à l'aise d'utiliser des API non publiques.

Answer 2

À mon avis, le code source en "Java+Lombok" n'est plus du tout du code source Java. Je vois cela comme quelque chose de similaire à ce que la société Borland a fait il y a de nombreuses années dans son IDE Borland C++ Builder pour VCL - ils ont introduit des "propriétés" dans le code C++ introduisant effectivement une sorte de nouveau langage de programmation qui n'était plus C++ (pas C++ dans le sens du standard du langage C++). Les sources utilisant "Java+Lombok" ne sont pas des sources valides au sens des spécifications du langage Java. De plus, je pense que les annotations n'ont pas été conçues pour influencer la sémantique du langage.

Answer 3

Le soutien de l'IDE constitue un inconvénient majeur. Étant donné que Lombok n'est pas un changement de langage, et que votre IDE ne comprend que java, vous aurez besoin d'un IDE qui supporte Lombok pour que les choses fonctionnent correctement. A partir de maintenant, c'est seulement Eclipse qui comprend Eclipse et IntelliJ. Si vous utilisez Eclipse, cela peut convenir, mais n'oubliez pas que vous prenez une décision pour les futurs développeurs également.

Je vous suggère d'envisager de déplacer une partie de votre code dans un langage moins cérémonieux tel que groovy. Nous avons réussi à transférer une partie de notre logique commerciale et de nos modèles en groovy et cela fonctionne très bien.

Answer 4

Un inconvénient potentiel de quelque chose comme Lombok est qu'avec les setters/getters "manquants", les outils sources peuvent ne pas "reconnaître" les aspects de l'objet résultant qui lui donnent des qualités de "haricot", puisque ces qualités ne se manifestent que dans la classe compilée.

Un autre inconvénient est qu'il s'agit d'un autre élément de "magie noire" dans la chaîne d'outils. Heureusement, il semble que ce soit une pièce plutôt bénigne (je ne l'ai pas utilisée), et le fait qu'elle se produise au moment de la compilation plutôt qu'au moment de l'exécution est en fait une bénédiction (IMHO). Mais, vous ne serez pas en mesure de réutiliser ou de partager votre code sans le projet puisqu'il ajoute des artefacts à votre base de code. Ainsi, si le fichier de classe compilé peut être un "POJO", je dirais que votre code source n'est PAS un POJO.

Il ne s'agit pas d'inconvénients rédhibitoires, mais plutôt d'aspects à prendre en compte pour l'avenir.

Answer 5

Il s'agit d'une bibliothèque tierce, et certains développeurs ne la connaissent pas bien.

L'IDE doit supporter le traitement des annotations (il existe des plugins pour IDEA et Eclipse).

Comme il a été mentionné ci-dessus, votre code sera sans getters/setters. Cela conduit à des violations de sonar/checkstyle.