Est-il sécuritaire d'utiliser le projet Lombok? [fermé]

vient de commencer à utiliser Lombok aujourd'hui. Jusqu'à présent, je l'aime, mais un inconvénient que je n'ai pas vu mentionné était le soutien de remaniement.

si vous avez une classe annotée avec @Data , elle générera les getters et setters pour vous basés sur les noms de champ. Si vous utilisez un de ces getters dans une autre classe, puis décider que le champ est mal nommé, il ne trouvera pas les usages de ces getters et setters et remplacer 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 (Jan 22 '13)

Après avoir utilisé Lombok pendant 3 mois, je le recommande encore pour la plupart des projets. J'ai cependant trouvé un autre inconvénient semblable à celui mentionné ci-dessus.

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

utilisant les méthodes de génération de délégués Eclipse..."vous fournit la même fonctionnalité, est tout aussi rapide et fournit le saut de source. L'inconvénient est qu'il encombre votre source avec le code boilerplate qui prennent la mise au point de la chose importante.

mise à jour 2 (fév. 26 '13)

Après 5 mois, on utilise encore Lombok, mais j'ai d'autres ennuis. L'absence d'un getter & setter déclaré peut devenir ennuyeux à certains moments quand vous essayez de vous familiariser avec le 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 à sauter pour déterminer le but de cette méthode. Certains de la les obstacles sont Lombok, certains sont le manque D'un plugin intelligent Lombok. Les obstacles comprennent:

• manque de JavaDocs. Si je javadoc the field, j'espère que le getter et le setter hériteront de ce javadoc à travers L'étape de compilation de Lombok.
• saut à la définition de méthode me saute à la classe, mais pas la propriété qui a généré le getter. C'est un plugin question.
• Évidemment, 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.
• NOTE: cette recherche de référence n'est pas un problème comme je l'ai d'abord pensé. Vous avez besoin d'utiliser une perspective qui permet la vue de contour cependant. 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. 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 être en mesure de rechercher des références.

mise à jour 3 (mars 7 '13)

Apprendre à utiliser les différentes façons de faire les choses dans Eclipse, je suppose. Vous pouvez en fait définir un point de rupture conditionnel (BP) sur une méthode générée par Lombok. En utilisant la vue Outline , vous pouvez Droit-cliquer la méthode à Toggle Method Breakpoint . Ensuite, lorsque vous appuyez sur la BP, vous pouvez utiliser la vue de débogage Variables pour voir ce que le la méthode générée a nommé les paramètres (habituellement le même que le nom du champ) et enfin, utilisez la vue Breakpoints pour faire un clic droit sur la BP et sélectionnez Breakpoint Properties... pour ajouter une condition. Beau.

mise à jour 4 (août 16 '13)

Netbeans n'aime pas quand vous mettez à jour vos dépendances Lombok dans votre Maven pom. Le projet compile toujours, mais les fichiers sont signalés pour avoir des erreurs de compilation parce qu'il ne peut pas voir les méthodes Lombok est la création. Nettoyer le cache Netbeans résout le problème. Pas sûr s'il y a une option" Clean Project " comme dans Eclipse. Problème mineur, mais je voulais la faire connaître.

mise à jour 5 (Jan 17 '14)

Lombok ne joue pas toujours bien avec Groovy, ou du moins le groovy-eclipse-compiler . Vous pourriez devoir déclasser votre version du compilateur. Maven Groovy and Java + Lombok

mise à jour 6 (juin 26 '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 va ennuyer la pisse hors de vous. Vous avez peut-être mieux de ne jamais l'utiliser.

mise à jour 7 (juil. 23 '14)

C'est un peu une mise à jour intéressante, car elle s'adresse directement au sécurité de l'adoption de Lombok que l'OP a demandé à propos.

à partir de v1.14, l'annotation @Delegate a été rétrogradée à un statut Expérimental. Les détails sont documentés sur leur site ( Lombok Délégué Docs ).

le truc c'est que, si vous utilisiez cette fonctionnalité, vos options de backout sont limitées. Je vois les options comme:

• supprimer manuellement @Delegate annotations et générer / hand-code le code délégué. C'est un peu plus difficile si vous utilisiez des attributs dans l'annotation.
• Delombok les fichiers qui ont l'annotation @Delegate et peut-être ajouter en arrière dans les annotations que vous voulez.
• Ne jamais mettre à jour Lombok ou maintenir une fourchette (ou vivre en utilisant des fonctionnalités expérientielles).
• Delombok votre projet entier et arrêter D'utiliser Lombok.

autant que je puisse dire, Delombok n'a pas d'option pour supprimer un sous-ensemble d'annotations ; c'est tout ou rien du tout pour le contexte d'un seul fichier. J'ai ouvert un billet pour demander cette fonctionnalité avec des drapeaux Delombok, mais je ne m'y attendrais pas dans un avenir proche.

mise à jour 8 (Oct 20 '14)

Si c'est une option pour vous, Groovy offre la plupart des mêmes avantages de Lombok, plus une charge de bateau d'autres caractéristiques, y compris @Delegate . Si vous pensez que vous aurez du mal à vendre l'idée aux pouvoirs qui seront, jetez un oeil à la @CompileStatic ou @TypeChecked annotation pour voir si cela peut aider votre cause. En fait, L'objectif principal de la version Groovy 2.0 était la sécurité statique .

mise à jour 9 (Sep 1 '15)

Lombok est toujours activement maintenu et amélioré , ce qui augure bien du niveau de sécurité de l'adoption. Le @Builder annotations est l'une de mes nouveautés préférées.

mise à jour 10 (Nov. 17 '15)

Cela ne semble pas directement lié à la question de L'OP, mais mérite d'être partagé. Si vous êtes à la recherche d'outils pour vous aider à réduire la quantité de code réutilisable, que vous écrivez, vous peut également consulter Google Auto - en particulier AutoValue . Si vous regardez leur slide deck , la liste de Lombok comme une solution possible au problème qu'ils essaient 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)."
• les pirouettes de compilation sont non standard et fragiles
• "à notre avis, votre code N'est plus vraiment Java "

Je ne suis pas sûr à quel point je suis d'accord avec leur évaluation. Et compte tenu des cons D'AutoValue qui sont documentés dans les diapositives, je vais rester avec Lombok (si Groovy n'est pas une option).

mise à jour 11 (fév. 8 '16)

J'ai découvert Spring Roo a quelques similaires annotations . 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. Retirer aussi ne semble pas aussi facile que de-lombok. Lombok semble être le choix le plus sûr.

mise à jour 12 (fév. 17 '16)

Tout en essayant de trouver des justifications pour pourquoi il est sûr de faire venir Lombok pour le projet Je travaille actuellement sur, 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 désactiver certaines fonctionnalités que votre équipe juge dangereuses ou indésirables. Mieux encore, il peut aussi créer une configuration spécifique au répertoire avec différents paramètres. C'est génial.

UPDATE 13 (Oct 4 '16)

Si ce genre de chose compte pour vous, Oliver Gierke a estimé qu'il était sûr de ajouter Lombok au repos de données de printemps .

UPDATE 14 (Sep 26 '17)

Comme indiqué par @gavenkoa dans les commentaires sur la question OPs, le support du compilateur JDK9 n'est pas encore disponible (numéro 985). Il semble aussi que ce ne sera pas une solution facile pour L'équipe de Lombok d'obtenir autour.

UPDATE 15 (Mar 26 '18)

Le changelog de Lombok indique à partir de v1.16.20 " compilant lombok sur JDK1.9 est maintenant possible " même si #985 est toujours ouvert.

pour s'adapter à JDK9 ont nécessité quelques changements de rupture; tous isolés aux changements de configuration par défaut. C'est un peu inquiétant qu'ils ont présenté cassant les changements, mais la version n'a fait que supplanter le numéro de version" incrémental " (passant de v1.16.18 à v1.16.20). Puisque ce post était sur la sécurité, si vous aviez un yarn/npm comme le système de construction qui automatiquement mis à niveau à la dernière version incrémentale, vous pourriez être dans un réveil rude.

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 au sujet de ce que j'essaye de réaliser par rapport à IDE/propres implémentations de méthodes compliquées telles que hashcode & equals.

lors de l'utilisation de

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

il est beaucoup plus facile de garder Equals & HashCode cohérent et de garder la trace des champs qui sont évalués, que n'importe quel IDE/propre implémentation. Cela est particulièrement vrai lorsque vous êtes encore en ajoutant / suppression régulière des champs.

il en va de même pour l'annotation @ToString et ses paramètres qui communiquent clairement le comportement désiré en ce qui concerne les champs inclus / exclus, l'utilisation de getters ou l'accès au champ et que vous appeliez ou non super.toString() .

et encore une fois en annotant une classe entière avec @Getter ou @Setter(AccessLevel.NONE) (et en surpassant éventuellement toute méthode divergente) il est immédiatement clair quelles méthodes seront disponibles pour le Fields.

Les avantages d'aller sur et sur..

dans mon esprit, il ne s'agit pas de réduire le code, mais de communiquer clairement ce que vous désirez accomplir, plutôt que d'avoir à le découvrir à partir de Javadoc ou de mises en œuvre. Le code réduit permet simplement de repérer plus facilement toute implémentation de méthode divergente.

Lombok est grand, mais...

Lombok enfreint les règles du traitement d'annotation, en ce qu'il ne génère pas de nouveaux fichiers source. Cela signifie qu'il ne peut pas être utilisé avec un autre processeur d'annotation s'ils s'attendent à ce que les getters/setters ou quoi que ce soit d'autre existe.

le traitement des annotations s'exécute en une série de rounds. À chaque tour, chacun reçoit un tour de course. Si de nouveaux fichiers java sont trouvés après le round, un autre round commence. Dans ce ainsi, l'ordre des processeurs d'annotation n'a pas d'importance s'ils ne génèrent que de nouveaux fichiers. Comme lombok ne génère pas de nouveaux fichiers, aucun nouveau rounds n'est lancé, de sorte que certains AP qui s'appuient sur le code lombok ne fonctionnent pas comme prévu. Cela a été une énorme source de douleur pour moi tout en utilisant mapstruct, et 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 construction pour travailler à la fois avec lombok et mapstruct. Mais je veux laisser tomber lombok comment hacky il est, dans ce projet, au moins. J'utilise lombok tout le temps à d'autres choses.

il y a aussi des risques d'entretien à long terme. Tout d'abord, je recommande la lecture sur la façon dont Lombok fonctionne réellement, 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 piratage total. Utilisation de L'API non publique. Casting présomptueux (sachant qu'une annotation cadencé en javac aura une instance de JavacAnnotationProcessor, qui est la mise en œuvre interne de Annotationprocesseur (une interface), qui se trouve avoir un couple des méthodes supplémentaires qui sont utilisées pour obtenir à la vie AST).

sur eclipse, c'est sans doute pire (et encore plus robuste) - un agent java est utilisé pour injecter du code dans la classe grammar and parser d'eclipse, qui est bien sûr entièrement non-public API et totalement hors limite.

Si vous pouviez faire ce que lombok fait avec L'API standard, Je l'aurais fait c'est comme ça, mais tu ne peux pas. Pourtant, pour ce que ça vaut, j'ai développé le Eclipse plugin pour eclipse v3.5 fonctionnant sur java 1.6, et sans il a fait des changements sur eclipse v3.4 en cours d'exécution sur java 1.5 as eh bien, il n'est pas complètement fragile.

comme résumé, tandis que Lombok peut vous faire gagner du temps de développement, s'il y a une mise à jour javac non rétro compatible (par exemple une vulnérabilité atténuation) Lombok pourrait vous coincer avec une ancienne version de Java pendant que les développeurs se démènent pour mettre à jour leur utilisation de ces API internes. Si c'est un grave risque dépend évidemment du projet.

je sais que je suis en retard, mais je ne résiste pas à la tentation: quiconque aime Lombok devrait aussi regarder Scala. Beaucoup de bonnes idées que vous trouverez à Lombok font partie de la langue Scala.

sur votre question: il est certainement plus facile d'obtenir vos développeurs d'essayer Lombok que Scala. Essayez et s'ils aiment, essayez Scala.

tout comme un avertissement: J'aime Java, aussi!

j'ai utilisé Lombok dans presque tous mes projets pour un an, mais malheureusement supprimé. Au début, c'était très propre voie de développement, mais de la configuration de l'environnement de développement pour les nouveaux membres de l'équipe n'est pas très facile et simple. Quand c'est devenu un mal de tête, je l'ai enlevé. Mais c'est un bon travail et a besoin de plus de simplicité à la mise en place.

quand j'ai montré le projet à mon équipe l'enthousiasme était grand, donc 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 s'agit d'un snap à intégrer, et ne nécessite aucun changement de code dans sa forme de base. (il suffit d'ajouter une seule annotation à votre classe)

• et enfin, si vous changez d'AVIS, vous pouvez lancer le unlombok, ou laisser votre IDE créer ces setters, getters, et ctors, (qui Je pense que personne ne va demander une fois qu'ils voient comment effacer votre pojo devient)

voulait utiliser le @ToString de lombok mais a vite fait face à des erreurs de compilation aléatoire sur le projet de reconstruction dans Intellij IDEA. A dû frapper la compilation plusieurs fois avant que la compilation incrémentielle puisse être terminée avec succès.

a essayé lombok 1.12.2 et 0.9.3 avec Intellij IDEA 12.1.6 et 13.0 sans aucun plugin lombok sous jdk 1.6.0_39 et 1.6.0_45.

a dû copier manuellement les méthodes générées par delomboked source et mettre lombok en attente jusqu'à ce que mieux temps.

mise à Jour

le problème ne se produit que lorsque la compilation parallèle est activée.

a déposé une question: https://github.com/rzwitserloot/lombok/issues/648

mise à Jour

mplushnikov a commenté le 30 janvier 2016:

nouvelle version D'Intellij n'a pas de telles questions plus. Je pense qu'il peut être fermé ici.

mise à Jour

je recommande fortement de passer de Java+Lombok à Kotlin si possible. Comme il a résolu à partir de la base tous les problèmes Java que Lombok essaie de travailler autour.

j'ai rencontré un problème avec Lombok et Jackson CSV , quand j'ai marshalisé mon objet (Java bean) à un fichier CSV, les colonnes où dupliqué, puis j'ai enlevé @annotation de Lombok données et marshalizing travaillé très bien.

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

lors du premier contact avec Lombok, j'ai eu une mauvaise impression. Après quelques semaines, j'ai commencé à l'aimer. Mais après quelques mois, j'ai découvert beaucoup de petits problèmes en l'utilisant. Donc, ma dernière impression sur Lombok n'est pas si positive.

Mes raisons de penser de cette façon:

• dépendance de plugin IDE . Le support IDE de Lombok se fait par le biais de plugins. Même en travaillant correctement la plupart du temps, vous êtes toujours un otage de ces plugins à maintenir dans les futures versions de L'IDEs et même du 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 n'ai pas pu le faire car il y a un problème sur la version du plugin lombok et j'ai besoin d'attendre que le plugin soit mis à jour... C'est aussi une problème si vous souhaitez utiliser un IDE plus alternatif qui n'a pas de prise en charge du plugin Lombok.
• " Trouver des usages problème. . En utilisant Lombok vous ne voyez pas le getter généré, le setter, le constructeur, les méthodes de constructeur et etc. Donc, si vous prévoyez de découvrir ce que de ces méthodes sont en train d'utiliser dans votre projet par votre IDE, vous ne pouvez pas le faire en recherchant seulement la classe qui possède ces méthodes.
• So 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 à ce que les développeurs ne contrôlent plus les méthodes qui doivent être visibles ou non. Donc, souvent ils copient et collent des annotations @Getter @Setter @Builder @AllArgsConstructor @NoArgsConstructor sans penser à ce dont la classe a vraiment besoin.
• Générateur De Obssession ©. J'ai inventé ce nom (lâche-moi, Martin Fowler). Blague à part, un constructeur est si facile à créer que même quand une classe A seulement deux paramètres 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 constructeur à l'intérieur du lombok Builder, créant des situations bizarres comme MyClass.builder().name("Name").build().create() .
• Obstacles lors d'un refactoring . Si vous utilisez, par exemple, un @AllArgsConstructor et que vous avez besoin d'ajouter un paramètre supplémentaire sur le constructeur, L'IDE ne peut pas vous aider à ajouter ce paramètre supplémentaire dans tous les endroits (la plupart du temps, des tests) qui instancient la classe.
• Mélange de 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. On s'y habitue après un certain temps, mais on dirait un piratage de la langue.

comme une autre réponse dit, si vous êtes en colère au sujet de la verbosité Java et l'utilisation Lombok à traiter avec elle, essayez de Kotlin.

mon point de vue sur Lombok est qu'il fournit simplement des raccourcis pour écrire du code Java bolilerplate.

Quand il s'agit d'utiliser des raccourcis pour écrire du code Java bolilerplate, je me fie à de telles fonctionnalités fournies par IDE -- comme dans Eclipse, nous pouvons aller à menu Source > Generate Getters et Setters pour générer getters et setters.

Je ne compterais pas sur une bibliothèque comme Lombok pour cela:

1. il pollue votre code avec une couche indirecte de syntaxe alternative (lire @Getter , @Setter , etc. annotation.) Plutôt que d'apprendre une syntaxe alternative pour Java, je changerais n'importe quel autre langage qui fournit nativement la syntaxe de type Lombok.
2. Lombok nécessite l'utilisation d'un IDE compatible avec Lombok pour fonctionner avec votre code. Cette dépendance présente un risque considérable pour tout projet non trivial. L'open source Lombok projet ont assez de ressources pour continuer à fournir un soutien pour différentes versions D'une large gamme D'IDE Java disponibles?
3. est-ce que L'open source Lombok project dispose de suffisamment de ressources pour continuer à prendre en charge les nouvelles versions de Java qui viendront à l'avenir?
4. je me sens également nerveux que Lombok puisse introduire des problèmes de compatibilité avec les cadres/bibliothèques largement utilisés (comme Spring, Hibernate, Jackson, JUnit, Mockito) qui fonctionnent avec votre code octet à l'exécution.

Dans l'ensemble je 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, c'était brouiller mes codes. Je dois supprimer lombok dans tous les fichiers de mes projets. Il y a delombok, mais comment être sûr que ça ne bousillerait pas mes codes? Je dois passer des jours à enlever 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 a causé des problèmes importants pour lui, et le travail correctif était encore en cours Il ya une semaine. Ma source pour ça est https://code.google.com/p/projectlombok/issues/detail?id=451 .