Quels sont les risques avec le projet Lombok?
Je viens avec des objectifs de performance pour la nouvelle année, et je pensais que je serais amusant de mettre un objectif pour réduire la taille de la base de code, en particulier passe-partout. Une action que j'ai trouvée pour résoudre ce problème est d'utiliser Project 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 approches, donc je compte sur la communauté Stack Overflow: Quelqu'un peut-il me dire pourquoi Lombok est une mauvaise idée?
6 answers
Un inconvénient majeur est le support ID. Puisque Lombok n'est pas réellement un changement de langue, et puisque votreE ne comprend que java, vous aurez besoin d'un ID qui prend en charge Lombok pour que les choses fonctionnent correctement. Pour l'instant, c'est seulement Eclipse qui inclut Eclipse et IntelliJ. Si vous utilisez Eclipse, cela peut être correct, mais rappelez-vous que vous prenez également une décision pour les futurs développeurs.
Je vous suggère d'envisager de déplacer une partie de votre code dans un langage moins cérémoniel tel que groovy. Nous avons réussi à transférer certains de nos modèles et de notre logique métier vers groovy et cela fonctionne très bien.
Une limitation de Lombok est le fait qu'il est étroitement lié au compilateur java. Étant donné que l'API du processeur d'annotation 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 des API non publiques. Utiliser lombok peut être une bonne idée, mais vous devez être conscient que la mise à niveau de votre compilateur peut casser votre code. Le la probabilité est faible mais je me sens toujours mal à l'aise d'utiliser des API non publiques.
Un inconvénient potentiel de quelque chose comme Lombok est qu'avec les setters/getters "manquants", les outils source peuvent ne pas "reconnaître" les aspects de l'objet résultant qui lui donnent des qualités de "bean", car ces qualités ne se manifestent que dans la classe compilée.
Un autre inconvénient est que c'est encore un autre morceau de "magie noire" dans la chaîne d'outils. Heureusement, cela semble être une pièce plutôt bénigne (je ne l'ai pas utilisée), et le fait que cela se produise au moment de la compilation plutôt que de l'exécution est en fait une bénédiction (à mon humble avis). Mais, vous ne pourrez pas réutiliser ou partager votre code sans le projet car il ajoute des artefacts à votre base de code. Ainsi, bien que le fichier de classe compilé puisse être un "POJO", je dirais que votre code source n'est PAS un POJO.
Aucun d'entre eux ne sont des inconvénients paralysants, plutôt que des aspects à prendre conscience de regarder vers l'avenir.
À mon avis, le code source dans "Java+Lombok" n'est plus du code source Java. Je le vois comme quelque chose de similaire que Borland company a fait il y a de nombreuses années dans son Builder Borland C++ Builder pour VCL - ils ont introduit des "propriétés" dans le code C++ introduisant efficacement une sorte de nouveau langage de programmation qui n'était plus C++ (pas C++ au sens de standard du langage C++). Les sources utilisant "Java + Lombok" ne sont pas des sources valides au sens de la spécification du langage Java. De plus je pense que les annotations ne l'étaient pas conçu pour influencer la sémantique du langage.
C'est une bibliothèque tierce, et il y a des développeurs qui ne la connaissent pas bien.
ID devrait prendre en charge le traitement des annotations (il existe des plugins pour IDEA et Eclipse).
Comme mentionné ci-dessus, votre code sera sans getters/setters. Cela conduit à des violations de sonar/checkstyle.
Comme l'a souligné l'utilisateur @Jcs dans une autre réponse, je voudrais en ajouter plus.
Dans notre projet, nous utilisons mapstruct qui est utilisé pour générer des classes de mappeur, avant que le code ne soit compilé, en utilisant la commande mvn generate-sources, cela se fait au stade du processus en utilisant le plugin de processeur maven.
Project lombok ajoute le bytecode pour le getter/setter dans le fichier de classe à la phase de compilation.
Puisque la phase de processus est exécutée avant la compilation, il constate qu'il n'y a pas getter / setter disponible en classe.
Il existe des solutions de contournement disponibles pour exécuter plusieurs phases de compilation. Voir ce git hub billet pour plus de détails.
Remarque: J'utilise STS id par Spring et il est supporté par lombok:)