Est-il sécuritaire d’utiliser le projet Lombok?

Au cas où vous ne le sauriez pas, Project Lombok aide avec certains des inconvénients de Java avec des choses comme générer des getters et des setters avec des annotations et même une simple génération JavaBean avec @Data . Cela pourrait vraiment m’aider, en particulier dans 50 objects d’événement différents où vous avez jusqu’à 7 champs différents à construire et à masquer avec des getters. Je pourrais enlever presque mille lignes de code avec ceci.

Cependant, je crains que ce ne soit une décision regrettable à long terme. Flamewars va éclater dans le canal ##Java Freenode lorsque je le mentionne, à condition que les extraits de code confondent les aides possibles, les gens se plaindront de l’absence de JavaDoc , et les futurs commettants pourraient tout simplement supprimer tout cela. J’apprécierais vraiment le positif, mais je suis inquiet pour le négatif.

Donc, est-il sûr d’utiliser Lombok sur un projet, petit ou grand? Les effets positifs valent-ils les négatifs?

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

Avant d’utiliser Project Lombok (ou toute autre technologie révolutionnaire) 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:

Les Flammes apparaîtront dans le canal ## Java Freenode quand je le mentionnerai,

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

fournir des extraits de code va confondre les assistants possibles,

Si la stratégie du projet consiste à utiliser Lombok, les assistants éventuels devront s’y habituer.

les gens vont se plaindre de l’absence de JavaDoc,

C’est leur problème. Personne dans leur bon esprit n’essaie d’appliquer de manière rigide les règles de code source / documentation de leur organisation à des logiciels open source tiers. L’équipe du projet devrait être libre de définir des normes de code source / documentation du projet adaptées à la technologie utilisée.

( FOLLOWUP – 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. S’il s’agit d’un problème majeur pour vos projets, vous pouvez créer et soumettre un patch Lombok pour résoudre ce problème. )

et les futurs commanditaires pourraient tout simplement supprimer tout cela de toute façon.

Ce n’est pas sur! Si la stratégie de projet convenue consiste à utiliser Lombok, alors les organisateurs qui en facturent gratuitement le code devraient être réprimandés et, si nécessaire, se voir retirer leurs droits de commettre.

Bien sûr, cela suppose que les parties prenantes vous ont accepté … y compris les développeurs. Et cela suppose que vous êtes prêt à défendre votre cause et à gérer de manière appropriée les inévitables voix dissidentes.

Je viens juste de commencer à utiliser Lombok aujourd’hui. Jusqu’à présent, je l’aime bien, mais un inconvénient que je n’ai pas vu mentionné était le support de refactoring.

Si vous avez une classe annotée avec @Data , cela générera les getters et les setters pour vous en fonction des noms de champs. Si vous utilisez l’un de ces getters dans une autre classe, puis 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 nom.

J’imagine que cela devrait être fait 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 cependant trouvé un autre inconvénient similaire à celui indiqué ci-dessus.

Si vous avez une classe, disons MyCompoundObject.java qui a 2 membres, tous deux annotés avec @Delegate , disons myWidgets et myGadgets , lorsque vous appelez myCompoundObject.getThingies() depuis une autre classe, il est impossible de savoir s’il myCompoundObject.getThingies() au Widget ou au Gadget car vous ne pouvez plus sauter à la source dans l’EDI.

L’utilisation de l’Eclipse “Générer des méthodes de délégation …” vous fournit les mêmes fonctionnalités, est tout aussi rapide et fournit des sauts de source. L’inconvénient est qu’il encombre votre source avec un code standard qui détourne l’attention des choses importantes.

MISE À JOUR 2 (26 février 2013)
Après 5 mois, nous utilisons toujours Lombok, mais j’ai d’autres ennuis. L’absence d’un getter et d’un setter déclarés peut devenir ennuyeux lorsque vous essayez de vous familiariser avec un nouveau code.

Par exemple, si je vois une méthode appelée getDynamicCols() mais que je ne sais pas de quoi il s’agit, j’ai quelques obstacles supplémentaires à franchir pour déterminer l’objective de cette méthode. Certains des obstacles sont Lombok, d’autres le manque de plugin intelligent Lombok. Les haies comprennent:

  • Manque de JavaDocs. Si je javadoc le champ, j’espère que le getter et le setter hériteront de ce javadoc au cours de l’étape de compilation de Lombok.
  • Aller à la définition de la méthode me conduit à la classe, mais pas à la propriété qui a généré le getter. Ceci est un problème de plugin.
  • De toute évidence, vous n’êtes pas en mesure de définir un point d’arrêt dans un getter / setter, sauf si vous générez ou codez la méthode.
  • Remarque: cette recherche de référence n’est pas un problème comme je le pensais pour la première fois. Cependant, vous devez utiliser une perspective qui active la vue Structure. Pas un problème pour la plupart des développeurs. Mon problème était que j’utilisais Mylyn qui filtrait ma vue Outline , donc je n’ai pas vu les méthodes. Manque 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 des références.

MISE À JOUR 3 (7 mars 13)
Apprendre à utiliser les différentes manières de faire les choses dans Eclipse, je suppose. Vous pouvez effectivement définir un point d’arrêt conditionnel (BP) sur une méthode générée par Lombok. En utilisant la vue Outline , vous pouvez cliquer avec le bouton droit sur la méthode pour Toggle Method Breakpoint . Ensuite, lorsque vous cliquez sur le BP, vous pouvez utiliser la vue Variables débogage pour voir comment la méthode générée a nommé les parameters (généralement les mêmes que le nom du champ) et utiliser la vue Breakpoints pour cliquer avec le bouton droit sur le BP et sélectionner Breakpoint Properties... pour append une condition. Agréable.

MISE À JOUR 4 (16 août 13)
Netbeans ne l’aime pas lorsque vous mettez à jour vos dépendances Lombok dans votre pom Maven. Le projet comstack toujours, mais les fichiers sont marqués pour avoir des erreurs de compilation car ils ne peuvent pas voir les méthodes créées par Lombok. Effacer le cache Netbeans résout le problème. Vous ne savez pas s’il existe une option “Clean Project” comme dans Eclipse. Problème mineur, mais voulait le faire savoir.

MISE À JOUR 5 (17 janvier 2014)
Lombok ne joue pas toujours bien avec Groovy, ou du moins le groovy-eclipse-comstackr . Vous devrez peut-être rétrograder votre version du compilateur. Maven Groovy et Java + Lombok

MISE À JOUR 6 (26 juin 2014)
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, cela vous agacera. Vous feriez peut-être mieux de ne jamais l’utiliser.

MISE À JOUR 7 (23 juillet 2014)
Cette mise à jour est un peu intéressante car elle concerne directement la sécurité de l’adoption de Lombok dont le PO a parlé.

A partir de la version v1.14, l’annotation @Delegate a été rétrogradée en statut Experimental. Les détails sont documentés sur leur site ( Docs Délégué Lombok ).

Le fait est que si vous utilisiez cette fonctionnalité, vos options de backout sont limitées. Je vois les options comme:

  • Supprimez manuellement les annotations @Delegate et générez / handcode le code délégué. C’est un peu plus difficile si vous utilisiez des atsortingbuts dans l’annotation.
  • Delombok les fichiers qui ont l’annotation @Delegate et peut-être rappend dans les annotations que vous voulez.
  • Ne jamais mettre à jour Lombok ou maintenir un fork (ou utiliser des fonctionnalités expérientielles).
  • Détruisez tout votre projet et arrêtez d’utiliser Lombok.

Autant que je sache , Delombok n’a pas la possibilité de supprimer un sous-ensemble d’annotations . c’est tout ou rien au moins pour le contexte d’un seul fichier. J’ai ouvert un ticket pour demander cette fonctionnalité avec les drapeaux Delombok, mais je ne m’attendrais pas à cela dans un avenir proche.

MISE À JOUR 8 (20 octobre 2014)
Si c’est une option pour vous, Groovy offre la plupart des avantages de Lombok, en plus d’une charge de bateau d’autres fonctionnalités, dont @Delegate . Si vous pensez que vous aurez du mal à vendre l’idée aux pouvoirs en place, consultez l’annotation @ComstackStatic ou @TypeChecked pour voir si cela peut aider votre cause. En fait, l’objective principal de la version 2.0 de Groovy était la sécurité statique .

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

MISE À JOUR 10 (17 novembre 15)
Cela peut ne pas sembler directement lié à la question du PO, mais mérite d’être partagée. Si vous recherchez des outils pour vous aider à réduire la quantité de code standard que vous écrivez, vous pouvez également consulter Google Auto , en particulier AutoValue . Si vous regardez leur diapositive , la liste Lombok est une solution possible au problème qu’ils tentent de résoudre. Les inconvénients listés pour Lombok sont:

  • Le code inséré est invisible (vous ne pouvez pas “voir” les méthodes qu’il génère) [ed note – en fait, vous pouvez le faire, mais il suffit d’un décompilateur]
  • Les hacks du compilateur sont non standard et fragiles
  • “A notre avis, votre code n’est plus vraiment Java”

Je ne suis pas sûr de combien je suis d’accord avec leur évaluation. Et étant donné les inconvénients de AutoValue qui sont documentés dans les diapositives, je vais restr avec Lombok (si Groovy n’est pas une option).

MISE À JOUR 11 (8 février 16)
J’ai découvert que Spring Roo avait des annotations similaires . J’ai été un peu surpris de découvrir que Roo est toujours une chose et trouver de la documentation pour les annotations est un peu difficile. L’enlèvement ne semble pas aussi facile que de-lombok. Lombok semble être le choix le plus sûr.

MISE À JOUR 12 (17 février 16)
Tout 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 la v1.14 – The Configuration System ! Cela signifie que vous pouvez configurer un projet pour supprimer 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 parameters. C’est génial.

MISE À JOUR 13 (4 octobre 16)
Si ce genre de chose compte pour vous, Oliver Gierke a estimé qu’il était prudent d’ append Lombok à Spring Data Rest .

MISE À JOUR 14 (26 septembre 17)
Comme indiqué par @gavenkoa dans les commentaires sur la question des OP, le support du compilateur JDK9 n’est pas encore disponible (problème n ° 985). Il semble également que cela ne sera pas une solution facile pour l’équipe de Lombok.

MISE À JOUR 15 (26 mars 18)
Le changelog 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 modifications apscopes pour prendre en charge JDK9 ont toutefois nécessité des changements importants. tous isolés aux changements dans les parameters de configuration par défaut. C’est un peu inquiétant qu’ils aient introduit des changements de rupture, mais la version ne s’est heurtée qu’au numéro de version “Incremental” (allant de la v1.16.18 à la v1.16.20). Étant donné que cet article concernait la sécurité, si vous aviez un système de génération similaire à un yarn/npm qui a automatiquement été mis à niveau vers la dernière version incrémentielle, vous pourriez être confronté à un réveil brutal.

Allez-y et utilisez Lombok, vous pouvez si nécessaire “delombok” votre code après http://projectlombok.org/features/delombok.html

Personnellement (et donc subjectivement), j’ai trouvé que l’utilisation de Lombok rend mon code plus expressif par rapport à ce que j’essaie de réaliser par rapport aux implémentations IDE / propres de méthodes complexes telles que le hashcode et ses équivalents.

En utilisant

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

Il est beaucoup plus facile de garder Equals & HashCode cohérent et de garder une trace des champs évalués, que tout IDE / propre implémentation. Cela est particulièrement vrai lorsque vous ajoutez ou supprimez des champs régulièrement.

Il en va de même pour l’annotation @ToSsortingng et ses parameters qui communiquent clairement le comportement souhaité en ce qui concerne les champs inclus / exclus, l’utilisation des getters ou des access aux champs et d’appeler ou non super.toSsortingng() .

Et encore une fois en annotant une classe entière avec @Getter ou @Setter(AccessLevel.NONE) (et en @Setter(AccessLevel.NONE) éventuellement les méthodes divergentes), il est immédiatement clair quelles méthodes seront disponibles pour les champs.

Les avantages vont et viennent ..

En ce qui me concerne, il ne s’agit pas de réduire le code, mais de communiquer clairement ce que vous souhaitez réaliser, plutôt que de devoir vous débrouiller avec Javadoc ou ses implémentations. Le code réduit facilite simplement la détection des implémentations de méthodes divergentes.

Lombok est génial, mais …

Lombok enfreint les règles du traitement des annotations, en ce sens qu’il ne génère pas de nouveaux fichiers sources. Cela signifie qu’il ne peut pas être utilisé avec d’autres processeurs d’annotation s’ils attendent des getters / setters ou autre chose.

Le traitement des annotations s’exécute en une série de tours. A chaque tour, chacun a son tour à courir. Si de nouveaux fichiers Java sont trouvés après la fin du tour, un autre tour commence. De cette façon, l’ordre des processeurs d’annotation n’a pas d’importance s’ils génèrent uniquement de nouveaux fichiers. Comme lombok ne génère aucun nouveau fichier, aucun nouveau cycle n’est lancé, de sorte que certains AP reposant sur le code lombok ne s’exécutent pas comme prévu. Cela a été une énorme source de souffrance pour moi lors de l’utilisation de mapstruct, et le delombok-ing n’est pas une option utile car il détruit vos numéros de ligne dans les journaux.

J’ai finalement piraté un script de compilation pour travailler avec lombok et mapstruct. Mais je veux laisser tomber lombok à cause de son caractère pirate – au moins dans ce projet. J’utilise lombok tout le temps dans d’autres choses.

Il existe également des risques de maintenance à long terme. Tout d’abord, je vous recommande de lire comment fonctionne Lombok, par exemple certaines réponses de ses développeurs ici .

Le site officiel contient également une liste des inconvénients , y compris cette citation de Reinier Zwitserloot:

C’est un hack total. Utiliser une API non publique. Casting présomptueux (sachant qu’un processeur d’annotations fonctionnant sous javac obtiendra une instance de JavacAnnotationProcessor, qui est l’implémentation interne d’AnnotationProcessor (une interface), et qui possède deux méthodes supplémentaires utilisées pour accéder à l’AST AST) .

Sur eclipse, c’est sans doute pire (et pourtant plus robuste) – un agent Java est utilisé pour injecter du code dans la classe de syntaxe et d’parsing de l’éclipse, qui est bien entendu une API entièrement non publique et totalement interdite.

Si vous pouviez faire ce que fait lombok avec une API standard, je l’aurais fait de cette façon, mais vous ne le pouvez pas. Pourtant, pour ce que cela vaut, j’ai développé le plugin eclipse pour eclipse v3.5 fonctionnant sur java 1.6, et sans apporter de modifications, il a également fonctionné sur eclipse v3.4 sur java 1.5, donc ce n’est pas complètement fragile.

En résumé, bien que Lombok puisse vous faire gagner du temps de développement, s’il existe une mise à jour javac compatible avec les versions précédentes (par exemple, atténuation des vulnérabilités), Lombok risque de vous coincer avec une ancienne version de Java. API internes. Que ce soit un risque grave dépend évidemment du projet.

Je sais que je suis en retard, mais je ne peux pas résister à la tentation: quiconque aime Lombok devrait aussi jeter un coup d’œil à Scala. Beaucoup de bonnes idées que vous trouvez à Lombok font partie de la langue Scala.

Sur votre question: il est certainement plus facile de faire en sorte que vos développeurs essaient Lombok que Scala. Essayez-le et si cela vous plait, essayez Scala.

Juste comme un avertissement: j’aime Java aussi!

J’ai utilisé Lombok dans presque tous mes projets pendant un an mais je l’ai malheureusement retiré. Au début, c’était un mode de développement très propre, mais la mise en place de l’environnement de développement pour les nouveaux membres de l’équipe n’est pas très simple et directe. Quand c’est devenu un mal de tête, je l’ai enlevé. Mais c’est un bon travail et il faut plus de simplicité pour la mise en place.

Quand j’ai montré le projet à mon équipe, l’enthousiasme était grand, alors je pense que vous ne devriez pas avoir peur de la réponse de l’équipe.

  • En ce qui concerne le retour sur investissement, il est facile à intégrer et ne nécessite aucun changement de code dans sa forme de base. (il suffit d’append une annotation à votre classe)

  • Et enfin, si vous changez d’avis, vous pouvez lancer le dé délocking, ou laisser votre EDI créer ces régleurs, getters et ctors (ce qui, je pense, personne ne le demandera une fois qu’ils verront à quel point votre pojo devient clair)

Voulait utiliser @ToSsortingng de lombok mais a rapidement fait face à des erreurs de compilation aléatoires lors de la reconstruction du projet dans Intellij IDEA. Il a fallu bash la compilation plusieurs fois avant que la compilation incrémentielle puisse aboutir avec succès.

J’ai essayé à la fois lombok 1.12.2 et 0.9.3 avec Intellij IDEA 12.1.6 et 13.0 sans aucun plug-in lombok sous jdk 1.6.0_39 et 1.6.0_45.

Doit manuellement copier les méthodes générées à partir de la source délombée et mettre lombok en attente jusqu’à des temps meilleurs.

Mettre à jour

Le problème se produit uniquement avec la compilation parallèle activée.

A déposé un problème: https://github.com/rzwitserloot/lombok/issues/648

Mettre à jour

mplushnikov a commenté le 30 janvier 2016:

La version la plus récente d’Intellij ne présente plus de tels problèmes. Je pense que cela peut être fermé ici.

Mettre à jour

Je recommande fortement de passer de Java + Lombok à Kotlin si possible. Comme il a résolu depuis le début tous les problèmes de Java, Lombok essaie de les contourner.

J’ai rencontré un problème avec Lombok et Jackson CSV , lorsque j’ai regroupé mon object (java bean) dans un fichier CSV, les colonnes étant dupliquées, j’ai supprimé l’annotation @Data de Lombok et le marshalizing fonctionnait correctement.

J’ai lu quelques opinions sur le Lombok et en fait je l’utilise dans certains projets.

Eh bien, au premier contact avec Lombok, j’ai eu une mauvaise impression. Après quelques semaines, j’ai commencé à l’aimer. Mais après quelques mois, je découvre de très petits problèmes d’utilisation. Donc, mon impression finale sur Lombok n’est pas si positive.

Mes raisons de penser ainsi:

  • Dépendance du plug-in IDE . Le support IDE pour Lombok se fait via des plugins. Même en travaillant bien la plupart du temps, vous êtes toujours pris en otage par ces plugins à conserver dans les futures versions des IDE et même dans le langage (Java 10+ accélérera le développement du langage). Par exemple, j’ai essayé de mettre à jour de Intellij IDE 2017.3 à 2018.1 et je ne pouvais pas le faire car il y a un problème avec la version du plugin lombok et je dois attendre que le plugin soit mis à jour … aimerait utiliser un IDE plus alternatif sans support de plug-in Lombok.
  • Problème ‘Trouver les usages’ . En utilisant Lombok, vous ne voyez pas les méthodes de lecture, de définition, de construction, de génération, etc. générées. Ainsi, si vous envisagez d’utiliser ces méthodes dans votre projet, vous ne pouvez pas le faire uniquement chercher la classe qui possède cette méthode cachée.
  • Si facile que les développeurs ne se soucient pas de briser l’encapsulation . Je sais que ce n’est pas vraiment un problème de Lombok. Mais j’ai vu une plus grande tendance chez les développeurs à ne plus contrôler quelles méthodes doivent être visibles ou non. Ainsi, plusieurs fois, ils ne font que copier et coller les @Getter @Setter @Builder @AllArgsConstructor @NoArgsConstructor sans réfléchir à ce dont la classe a vraiment besoin.
  • Constructeur Obssession ©. J’ai inventé ce nom (Martin Fowler). Blague à part, un générateur est si facile à créer que même lorsqu’une classe n’a que deux parameters, les développeurs préfèrent utiliser @Builder au lieu de constructeur ou une méthode de constructeur statique. Parfois, ils essaient même de créer un Builder dans le générateur de Lombok, créant des situations étranges comme MyClass.builder().name("Name").build().create() .
  • Barrières lors du refactoring . Si vous utilisez, par exemple, un @AllArgsConstructor et que vous devez append un paramètre supplémentaire sur le constructeur, l’EDI ne peut pas vous aider à append ce paramètre supplémentaire à tous les endroits (principalement les tests) qui instancient la classe.
  • Mélanger Lombok avec des méthodes concrètes . Vous ne pouvez pas utiliser Lombok dans tous les scénarios pour créer un getter / setter / etc. Donc, vous verrez ces deux approches mélangées dans votre code. Vous vous habituez après un certain temps, mais vous vous sentez comme un hack sur le langage.

Comme une autre réponse, si vous êtes mécontent de la verbosité de Java et que vous utilisez Lombok, essayez Kotlin.

Mon sharepoint vue sur Lombok est qu’il ne fournit que des raccourcis pour écrire du code Java bolilerplate.
Quand il s’agit d’utiliser des raccourcis pour écrire du code Java bolilerplate, je me fierais à de telles fonctionnalités fournies par IDE.
Je ne compterais pas sur une bibliothèque comme Lombok pour cela:

  1. Il pollue votre code avec une couche d’indirection de syntaxe alternative (lire les @Getter , @Setter , etc.). Plutôt que d’apprendre une syntaxe alternative pour Java, je passerais à tout autre langage qui fournit nativement une syntaxe similaire à Lombok.
  2. Lombok nécessite l’utilisation d’un IDE compatible Lombok pour fonctionner avec votre code. Cette dépendance présente un risque considérable pour tout projet non sortingvial. Le projet open source Lombok dispose-t-il de suffisamment de ressources pour continuer à prendre en charge différentes versions d’un large éventail de Java IDE?
  3. Le projet open source Lombok dispose-t-il de suffisamment de ressources pour continuer à prendre en charge les nouvelles versions de Java à venir?
  4. Je suis également nerveux que Lombok puisse introduire des problèmes de compatibilité avec des frameworks / bibliothèques largement utilisés (comme Spring, Hibernate, Jackson, JUnit, Mockito) qui fonctionnent avec votre code d’octet à l’exécution.

Dans l’ensemble, je ne préférerais pas “pimenter” mon Java avec Lombok.

Je ne le recommande pas J’avais l’habitude de l’utiliser, mais quand je travaille avec NetBeans 7.4, ça me gâchait. Je dois supprimer lombok dans tous les fichiers de mes projets. Il y a delombok, mais comment puis-je être sûr que cela ne viderait pas mes codes. Je dois passer des jours juste pour supprimer Lombok et revenir aux styles Java ordinaires. J’ai juste trop épicé …

Je n’ai pas encore essayé d’utiliser Lombok – il est / était le suivant sur ma liste, mais il semble que Java 8 ait causé des problèmes importants et que des travaux de réparation étaient en cours depuis une semaine. Ma source est https://code.google.com/p/projectlombok/issues/detail?id=451 .