L'utilisation du Projet Lombok est-elle sûre ?

Question

Au cas où vous ne le sauriez pas Projet Lombok permet d'éviter certains inconvénients de Java, comme par exemple générer des getters et setters avec des annotations et même génération simple de type JavaBean avec @Data . Cela pourrait vraiment m'aider, en particulier pour 50 objets d'événements différents où vous avez jusqu'à 7 champs différents qui doivent être construits et cachés avec des getters. Je pourrais ainsi supprimer près de mille lignes de code.

Cependant, j'ai peur qu'à long terme, ce soit une décision regrettable. Des guerres de mots éclateront dans le ##Java Freenode canal quand je le mentionne, fournir des extraits de code risque d'embrouiller les aides éventuelles, les gens se plaindront de l'absence de JavaDoc et les futurs auteurs pourraient tout supprimer de toute façon. J'apprécierais vraiment les aspects positifs, mais je m'inquiète des aspects négatifs.

Alors : Peut-on utiliser Lombok en toute sécurité pour tout projet, petit ou grand ? Les effets positifs valent-ils les inconvénients ?

Answer 1

J'ai commencé à utiliser Lombok aujourd'hui. Jusqu'à présent, j'aime bien, mais il y a un inconvénient que je n'ai pas vu mentionné, c'est le support du refactoring.

Si vous avez une classe annotée avec @Data il générera les getters et setters pour vous sur la base des noms de champs. Si vous utilisez un de ces getters dans une autre classe, et que vous décidez que le champ est mal nommé, il ne trouvera pas les utilisations de ces getters et setters et remplacera l'ancien nom par le nouveau.

J'imagine que cela doit se faire via un plug-in IDE et non via Lombok.

MISE À JOUR (22 janvier 13)
Après avoir utilisé Lombok pendant 3 mois, je le recommande toujours pour la plupart des projets. J'ai toutefois constaté un autre inconvénient, similaire à celui mentionné ci-dessus.

Si vous avez une classe, disons MyCompoundObject.java qui a 2 membres, tous deux annotés de @Delegate disons que myWidgets y myGadgets quand vous appelez myCompoundObject.getThingies() d'une autre classe, il est impossible de savoir si elle délègue à la Widget ou Gadget parce que vous ne pouvez plus sauter à la source dans l'IDE.

L'utilisation de la fonction "Generate Delegate Methods..." d'Eclipse vous offre la même fonctionnalité, est tout aussi rapide et fournit un saut de source. L'inconvénient est que cela encombre votre source de code passe-partout qui détourne l'attention des éléments importants.

MISE À JOUR 2 (26 février '13)
Après 5 mois, nous utilisons toujours Lombok, mais j'ai quelques autres désagréments. L'absence d'un getter et d'un setter déclarés peut être gênante lorsque vous essayez de vous familiariser avec un nouveau code.

Par exemple, si je vois une méthode appelée getDynamicCols() mais je ne sais pas de quoi il s'agit, j'ai quelques obstacles supplémentaires à franchir pour déterminer le but de cette méthode. Certains de ces obstacles sont dus à Lombok, d'autres à l'absence d'un plugin intelligent pour Lombok. Ces obstacles sont les suivants :

• Manque de JavaDocs. Si je fais une javadoc du champ, j'espère que les getter et setter hériteront de cette javadoc lors de l'étape de compilation de Lombok.
• Le saut vers la définition de la méthode m'amène à la classe, mais pas à la propriété qui a généré le getter. C'est un problème de plugin.
• Il est évident que vous ne pouvez pas définir un point d'arrêt dans un getter/setter à moins de générer ou de coder la méthode.
• NOTE : Cette recherche de référence n'est pas un problème comme je l'ai d'abord pensé. Vous devez cependant utiliser une perspective qui active la vue Outline. Ce n'est pas un problème pour la plupart des développeurs. Mon problème était que j'utilisais Mylyn qui filtrait mes résultats de recherche de référence. Outline donc je n'ai pas vu les méthodes. Absence de recherche de références. Si je veux voir qui appelle getDynamicCols(args...) Je dois générer ou coder le setter pour pouvoir rechercher les références.

MISE À JOUR 3 (7 mars '13)
Apprendre à utiliser les différentes façons de faire les choses dans Eclipse, je suppose. Vous pouvez en fait définir un point d'arrêt conditionnel (BP) sur une méthode générée par Lombok. En utilisant la méthode Outline vous pouvez cliquer avec le bouton droit de la souris sur la méthode pour Toggle Method Breakpoint . Ensuite, lorsque vous touchez la BP, vous pouvez utiliser le débogage. Variables pour voir comment la méthode générée a nommé les paramètres (généralement le même que le nom du champ) et enfin, utilisez la vue Breakpoints pour faire un clic droit sur la BP et sélectionner Breakpoint Properties... pour ajouter une condition. Bien.

MISE À JOUR 4 (16 août '13)
Netbeans n'apprécie pas que vous mettiez à jour vos dépendances Lombok dans votre pom Maven. Le projet se compile toujours, mais les fichiers sont signalés comme présentant des erreurs de compilation car ils ne peuvent pas voir les méthodes créées par Lombok. L'effacement du cache de Netbeans résout le problème. Je ne sais pas s'il existe une option "Nettoyer le projet" comme dans Eclipse. C'est un problème mineur, mais je voulais le faire savoir.

MISE À JOUR 5 (17 janvier '14)
Lombok ne fait pas toujours bon ménage avec Groovy, ou du moins avec la version groovy-eclipse-compiler . Vous devrez peut-être mettre à jour votre version du compilateur. Maven Groovy et Java + Lombok

MISE À JOUR 6 (26 juin '14)
Un mot d'avertissement. Lombok est légèrement addictif et si vous travaillez sur un projet où vous ne pouvez pas l'utiliser pour une raison quelconque, il vous ennuiera au plus haut point. Vous feriez peut-être mieux de ne pas l'utiliser du tout.

MISE À JOUR 7 (23 juillet '14)
Il s'agit d'une mise à jour un peu intéressante parce qu'elle s'adresse directement au sécurité d'adopter Lombok que l'OP a demandé.

À partir de la v1.14, le @Delegate a été rétrogradée au statut expérimental. Les détails sont documentés sur leur site ( Docs des délégués de Lombok ).

Le problème, c'est que si vous utilisez cette fonction, vos options de retour en arrière sont limitées. Je vois les options comme :

• Retirer manuellement @Delegate et de générer ou de coder manuellement le code du délégué. C'est un peu plus difficile si vous utilisez des attributs dans l'annotation.
• Delombok les fichiers qui ont le @Delegate et peut-être ajouter les annotations que vous voulez.
• Ne jamais mettre à jour Lombok ou maintenir un fork (ou vivre avec l'utilisation de fonctionnalités expérimentales).
• Delombok votre projet entier et arrêtez d'utiliser Lombok.

D'après ce que je sais, Delombok ne dispose pas d'une option permettant de supprimer un sous-ensemble d'annotations. c'est tout ou rien, du moins dans le contexte d'un seul fichier. J'ai ouvert un ticket pour demander cette fonctionnalité avec des drapeaux de Delombok, mais je ne m'attendrais pas à ça dans un futur proche.

MISE À JOUR 8 (20 octobre 14)
Si c'est une option pour vous, Groovy offre la plupart des mêmes avantages que Lombok, plus un tas d'autres fonctionnalités, notamment @Délégué . Si vous pensez que vous aurez du mal à faire accepter l'idée par les autorités, jetez un coup d'œil à l'initiative de la Commission européenne. @CompileStatic ou @TypeChecked pour voir si cela peut aider votre cause. En effet, le principal objectif de la version 2.0 de Groovy était la sécurité statique. .

MISE À JOUR 9 (1er septembre 15)
Lombok est toujours en train de maintenu et amélioré activement ce qui est de bon augure pour le niveau de sécurité de l'adoption. Le site @Builder Les annotations sont l'une de mes nouvelles fonctionnalités préférées.

MISE À JOUR 10 (17 nov. 15)
Cela peut ne pas sembler directement lié à la question de l'OP, mais cela vaut la peine de le partager. Si vous recherchez des outils pour vous aider à réduire la quantité de code passe-partout que vous écrivez, vous pouvez également consulter les sites suivants Google Auto - en particulier AutoValue . Si vous regardez leur diapositives Ils citent Lombok comme une solution possible au problème qu'ils tentent de résoudre. Les inconvénients qu'ils énumèrent pour Lombok sont :

• Le code inséré est invisible (vous ne pouvez pas "voir" les méthodes qu'il génère) [ndlr : en fait, vous pouvez, mais cela nécessite un décompilateur].
• Les hacks du compilateur sont non standard et fragiles
• "À notre avis, votre code n'est plus vraiment Java".

Je ne suis pas sûr d'être d'accord avec leur évaluation. Et étant donné les inconvénients d'AutoValue qui sont documentés dans les diapositives, je vais m'en tenir à Lombok (si Groovy n'est pas une option).

MISE À JOUR 11 (8 février 16)
J'ai découvert Spring Roo a quelques annotations similaires . J'ai été un peu surpris de découvrir que Roo existe toujours et que trouver de la documentation pour les annotations est un peu difficile. La suppression ne semble pas non plus aussi facile que la suppression de Lombok. Lombok semble être le choix le plus sûr.

MISE À JOUR 12 (17 février '16)
En essayant de trouver des justifications pour expliquer pourquoi il est sûr de faire venir Lombok pour le projet sur lequel je travaille actuellement, j'ai trouvé un morceau d'or qui a été ajouté avec v1.14 - Le Système de configuration ! Cela signifie que vous pouvez configurer un projet pour interdire certaines fonctionnalités que votre équipe juge dangereuses ou indésirables. Mieux encore, il peut également créer une configuration spécifique à un répertoire avec différents paramètres. C'est génial.

UPDATE 13 (4 oct. 16)
Si ce genre de chose compte pour vous, Oliver Gierke a estimé qu'il était sûr de ajouter Lombok à Spring Data Rest .

MISE À JOUR 14 (26 Sep '17)
Comme l'a souligné @gavenkoa dans les commentaires sur la question de l'OP, Le support du compilateur JDK9 n'est pas encore disponible (Numéro 985). Il semble également que ce ne sera pas une solution facile pour l'équipe Lombok.

UPDATE 15 (26 mars '18)
Le journal des modifications de Lombok indique qu'à partir de la v1.16.20 " La compilation de lombok sur JDK1.9 est maintenant possible " même si #985 est toujours ouvert.

Les changements pour s'adapter à JDK9, cependant, ont nécessité quelques changements de rupture ; tous isolés à des changements dans les valeurs par défaut de la configuration. C'est un peu inquiétant qu'ils aient introduit des changements de rupture, mais la version n'a fait qu'augmenter le numéro de version "Incremental" (passant de v1.16.18 à v1.16.20). Puisque ce post concernait la sécurité, si vous avez une yarn/npm comme un système de construction qui mettait automatiquement à niveau vers la dernière version incrémentale, vous risquez d'avoir un réveil brutal.

MISE À JOUR 16 (9 janvier 19)

Il semble les problèmes du JDK9 ont été résolus et Lombok fonctionne avec JDK10, et même JDK11 pour autant que je sache.

Une chose que j'ai remarquée et qui est préoccupante du point de vue de la sécurité est le fait que le journal des modifications entre la v1.18.2 et la v1.18.4 mentionne deux éléments comme étant BREAKING CHANGE ! ? Je ne suis pas sûr de savoir comment un changement de rupture se produit dans une mise à jour "patch" semver. Cela pourrait être un problème si vous utilisez un outil qui met à jour automatiquement les versions de patch.

MISE À JOUR 17 (17 mars '21)

Il y a un certain drame qui se déroule entre les développeurs de Lombok et un développeur d'OpenJDK autour du JDK 16. Les développeurs du JDK soutiennent que Lombok tire parti d'éléments internes non publiés du JDK par le biais de failles que l'équipe du JDK souhaiterait combler, mais qu'elle a intentionnellement laissées ouvertes pour diverses raisons.

Ils ont fait part de leur inquiétude (sur la sécurité de Lombok) comme tel :

Tous les accès aux internes resteront disponibles comme avant, à condition que l'application cliente l'autorise explicitement, en reconnaissant qu'elle assume qu'elle assume sciemment tout problème de maintenance (ou de sécurité) que cela pourrait que cela pourrait entraîner.

Lombok pourrait penser qu'ils trompent OpenJDK, mais ils font seulement c'est annoncer qu'ils ont l'intention de tromper leurs propres utilisateurs.

Il se peut qu'un jour prochain, Lombok ne soit plus en mesure de trouver des solutions créatives pour contourner les restrictions de sécurité du JDK. Même s'ils y parviennent, la sécurité de l'utilisation de Lombok dans votre projet peut être remise en question.

Answer 2

Il semble que vous ayez déjà décidé que le projet Lombok vous offre des avantages techniques importants pour votre nouveau projet. (Pour être clair dès le départ, je n'ai aucune opinion particulière sur le Projet Lombok, dans un sens ou dans l'autre).

Avant d'utiliser le projet Lombok (ou toute autre technologie susceptible de changer la donne) dans un projet (open source ou autre), vous devez vous assurer que les parties prenantes du projet sont d'accord. Cela inclut les développeurs et tous les utilisateurs importants (par exemple, les sponsors formels ou informels).

Vous mentionnez ces problèmes potentiels :

Des guerres de mots vont éclater dans le canal ##Java Freenode lorsque je le mentionnerai,

Facile. Ignorez / ne participez pas aux guerres de mots, ou abstenez-vous simplement de mentionner Lombok.

Fournir des extraits de code ne fera qu'embrouiller les aides éventuelles,

Si la stratégie du projet consiste à utiliser Lombok, les aides éventuelles devront s'y habituer.

les gens se plaindront de l'absence de JavaDoc,

C'est leur problème. Aucune personne saine d'esprit n'essaie d'appliquer de manière rigide les règles de son organisation en matière de code source et de documentation aux logiciels libres de tiers. L'équipe de projet devrait être libre de définir les normes de code source et de documentation du projet qui sont appropriées à la technologie utilisée.

( SUIVI - Les développeurs de Lombok reconnaissent que le fait de ne pas générer de commentaires javadoc pour les méthodes getter et setter synthétisées est un problème. Si cela constitue un problème majeur pour votre/vos projet(s), une alternative est de créer et de soumettre un patch Lombok pour résoudre ce problème).

et les futurs auteurs pourraient tout supprimer de toute façon.

Ce n'est pas sur ! Si la stratégie convenue pour le projet est d'utiliser Lombok, alors les auteurs qui dé-Lombokent gratuitement le code devraient être réprimandés, et si nécessaire se voir retirer leurs droits de commit.

Bien sûr, cela suppose que vous ayez l'adhésion des parties prenantes, y compris les développeurs. Et cela suppose que vous soyez prêt à défendre votre cause et à gérer de manière appropriée les inévitables voix discordantes.

Answer 3

Allez-y et utilisez Lombok, vous pouvez si nécessaire "delombok" votre code par la suite. http://projectlombok.org/features/delombok.html

Answer 4

Personnellement (et donc subjectivement), j'ai trouvé que l'utilisation de Lombok rendait mon code plus expressif quant à ce que j'essaie d'obtenir, par rapport aux implémentations propres à l'IDE de méthodes complexes telles que hashcode et equals.

Lorsque vous utilisez

@EqualsAndHashCode(callSuper = false, of = { "field1", "field2", "field3" })

il est beaucoup plus facile de garder Equals & HashCode cohérents et de garder la trace des champs qui sont évalués, que n'importe quelle IDE/implémentation propre. Ceci est particulièrement vrai lorsque vous ajoutez ou supprimez régulièrement des champs.

Il en va de même pour le @ToString et ses paramètres qui communiquent clairement le comportement souhaité en ce qui concerne les champs inclus/exclus, l'utilisation des récupérateurs ou l'accès aux champs, et l'appel ou non de l'annotation super.toString() .

Et encore, en annotant une classe entière de @Getter ou @Setter(AccessLevel.NONE) (et éventuellement en surchargeant toute méthode divergente), on sait immédiatement quelles méthodes seront disponibles pour les champs.

Les avantages ne s'arrêtent pas là.

Dans mon esprit, il ne s'agit pas de réduire le code, mais de communiquer clairement ce que vous souhaitez obtenir, plutôt que de devoir le découvrir dans la Javadoc ou les implémentations. Le code réduit permet simplement de repérer plus facilement les implémentations de méthodes divergentes.

Answer 5

Lorsque j'ai montré le projet à mon équipe, l'enthousiasme était grand, donc je pense que vous ne devez pas avoir peur de la réaction de l'équipe.

• En ce qui concerne le retour sur investissement, il est facile à intégrer et ne nécessite aucune modification du code dans sa forme de base. (il suffit d'ajouter une seule annotation à votre classe)

• Et enfin, si vous changez d'avis, vous pouvez exécuter le unlombok, ou laisser votre IDE créer ces setters, getters, et ctors, (ce que je pense que personne ne demandera une fois qu'ils verront comment votre pojo devient clair)