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

Comme l'a souligné l'utilisateur @Jcs dans une autre réponse, je voudrais en rajouter.

Dans notre projet, nous utilisons mapstruct qui est utilisé pour générer des classes de mapper, avant que le code ne soit compilé, en utilisant la commande mvn generate-sources, ceci est fait à la phase du processus en utilisant le plugin maven processor.

le projet lombok ajoute le bytecode pour le getter/setter dans le fichier de classe à la phase de compilation.

puisque la phase de traitement est exécutée avant la compilation, elle constate qu'il n'y a pas de getter/setter disponible dans la classe.

Il existe quelques solutions de contournement pour exécuter la phase de compilation à plusieurs reprises. Voir ce qui suit ticket git hub pour plus de détails.

Note : J'utilise STS ide de Spring et il est supporté par lombok :)

Answer 2

À mon avis, le risque le plus évident du projet Lombok est que lorsque vous décidez d'utiliser Lombok, vous décidez également que tous les autres utilisateurs de votre code utilisent Lombok. Cette affirmation est vraie pour toutes les bibliothèques, mais Lombok est spéciale dans la mesure où elle est dépendante de la construction et où votre IDE a besoin de plugins pour comprendre ce qui se passe. Cela signifie que quiconque a une raison de toucher à votre code (par exemple, quelqu'un qui essaie de déboguer un comportement bizarre, etc.) doit savoir comment le configurer et comment il fonctionne. Cela peut être un peu frustrant.

Answer 3

Pour ajouter aux autres réponses.

La principale raison de ne pas l'utiliser est une nouvelle record mot-clé ajouté comme fonctionnalité expérimentale dans Java 14. Java 16 apporte records en avant-première, ce qui rendra le projet Lombok obsolète dans la plupart des cas.

Depuis Java 14 on est capable d'écrire :

record Book(String title, String author, String isbn);

qui donne automatiquement accès aux méthodes constructor, getters/setter, hashCode, equals et toString sans aucune annotation.