使用龙目岛项目安全吗？[关闭]

StackOverflow https://stackoverflow.com/questions/3852091

  •  27-09-2019
  •  | 
  •  

题

如果你不知道 龙目岛计划 帮助解决 Java 的一些烦恼，比如 生成带注释的 getter 和 setter 乃至 使用 @Data 生成简单的 JavaBean 类. 。它确实对我有帮助，特别是在 50 个不同的事件对象中，其中最多有 7 个不同的字段需要使用 getter 构建和隐藏。我可以用这个删除近千行代码。

但我担心，从长远来看，这将是一个令人遗憾的决定。烈火战将在 ##Java Freenode 当我提到它时，提供代码片段会让可能的帮助者感到困惑， 人们会抱怨缺少 JavaDoc, ，未来的提交者可能会将其全部删除。我真的很喜欢积极的一面，但我担心消极的一面。

所以：在任何项目（无论大小）上使用 Lombok 是否安全？正面影响值得负面影响吗？

有帮助吗？

解决方案

这听起来像你已经决定了项目龙目岛为您提供了你提出的新项目显著的技术优势。 （为了清楚从一开始，我对项目Lombok的没有特别的观点，一种方式或另一种。）

在你在某些项目（开源的或其他方式）使用Project龙目岛（或其他任何改变游戏规则的技术），您需要确保该项目的股份持有人同意这一点。这包括开发人员和任何重要用户（例如正式或非正式赞助商）。

您提及这些潜在的问题：

  

论战将在##的Java Freenode的信道爆发时，我提到它，

易。忽略/不参加论战，或简单地从提Lombok的避免。

  

提供代码片段将可能的混淆帮手，

如果该项目的策略是使用龙目岛，则可能助手将需要习惯它。

  

人会抱怨缺少的JavaDoc，

这是他们的问题。没有人在他们的脑子试图严格适用其组织的源代码/文件规则的第三方开放源代码软件。项目团队应该可以自由地设定项目的源代码/文档的标准，适合于所使用的技术。

（后续 - 龙目开发商认识到合成的getter和setter方法不产生javadoc注释是一个问题，如果这是你的项目（S）的一个主要问题，那么一个替代方案是创建和提交补丁Lombok的解决这个问题。）

  

和未来commiters可能只是将其删除所有无妨。

这是不是！如果同意项目的策略是使用龙目岛，然后commiters谁无缘无故去龙目岛的代码应该被严惩，并在必要时已撤回承诺的权利。

当然，这是假定你已经有了买入从相关人士......包括开发商。并假定你准备争辩您的事业，并妥善处理必然反对的声音。

其他提示

今天刚开始使用Lombok。到目前为止，我很喜欢它，但我没有看到提到的一个缺点是重构支持。

如果您有一个带有注释的类 @Data, ，它会根据字段名称为您生成 getter 和 setter。如果您在另一个类中使用这些 getter 之一，那么确定该字段的命名不当，它将找不到这些 getter 和 setter 的用法，并用新名称替换旧名称。

我想这必须通过 IDE 插件而不是通过 Lombok 来完成。

更新（2013 年 1 月 22 日）
使用 Lombok 3 个月后，我仍然推荐它用于大多数项目。然而，我确实发现了另一个与上面列出的类似的缺点。

如果你有课，请说 MyCompoundObject.java 有 2 个成员，均注释为 @Delegate, ， 说 myWidgets 和 myGadgets, ， 你打电话时 myCompoundObject.getThingies() 来自另一个类，不可能知道它是否委托给 Widget 或者 Gadget 因为您无法再跳转到 IDE 中的源代码。

使用 Eclipse“生成委托方法...”为您提供相同的功能，速度同样快，并且提供源跳转。缺点是它会用样板代码扰乱您的源代码，从而使您无法集中精力关注重要的内容。

更新 2（2013 年 2 月 26 日）
5 个月后，我们仍在使用 Lombok，但我还有一些其他烦恼。当您试图熟悉新代码时，缺少声明的 getter 和 setter 有时会很烦人。

例如，如果我看到一个名为 getDynamicCols() 但我不知道它是关于什么的，我需要跨越一些额外的障碍来确定这个方法的目的。有些障碍是 Lombok，有些是缺乏 Lombok 智能插件。障碍包括：

  • 缺乏 JavaDocs。如果我对该字段进行 javadoc，我希望 getter 和 setter 能够通过 Lombok 编译步骤继承该 javadoc。
  • 跳转到方法定义会将我跳转到类，但不会跳转到生成 getter 的属性。这是一个插件问题。
  • 显然，除非生成或编写方法，否则无法在 getter/setter 中设置断点。
  • 笔记：这个参考搜索并不像我最初想象的那样是一个问题。不过，您确实需要使用启用大纲视图的透视图。对于大多数开发人员来说这不是问题。我的问题是我正在使用 Mylyn，它正在过滤我的 Outline view，所以我没有看到方法。 缺乏参考文献搜索。如果我想看看谁打来的电话 getDynamicCols(args...), ，我必须生成或编码设置器才能搜索引用。

更新 3（2013 年 3 月 7 日）
我想学习使用 Eclipse 中的各种做事方式。您实际上可以在 Lombok 生成的方法上设置条件断点 (BP)。使用 Outline 查看方法，可以右键单击该方法 Toggle Method Breakpoint. 。然后打到BP的时候就可以使用调试了 Variables 查看生成的方法命名的参数（通常与字段名称相同），最后使用 Breakpoints 查看右键单击 BP 并选择 Breakpoint Properties... 添加一个条件。好的。

更新 4（2013 年 8 月 16 日）
Netbeans 不喜欢您在 Maven pom 中更新 Lombok 依赖项。该项目仍然可以编译，但文件会被标记为存在编译错误，因为它看不到 Lombok 正在创建的方法。清除 Netbeans 缓存可以解决该问题。不确定是否有像 Eclipse 中那样的“Clean Project”选项。小问题，但想让大家知道。

更新 5（2014 年 1 月 17 日）
Lombok 并不总是能与 Groovy 很好地配合，或者至少是 groovy-eclipse-compiler. 。您可能必须降级编译器的版本。Maven Groovy 和 Java + Lombok

更新 6（2014 年 6 月 26 日）
一句警告。Lombok 有点容易让人上瘾，如果你从事的项目由于某种原因而无法使用它，它会让你恼火。您可能根本不使用它会更好。

更新 7（2014 年 7 月 23 日）
这是一个有趣的更新，因为它直接解决了 安全 OP 询问的采用 Lombok 的问题。

从 v1.14 开始， @Delegate 注释已降级为实验状态。详细信息记录在他们的网站上（Lombok 代表文档).

问题是，如果您使用此功能，您的撤销选项将受到限制。我看到的选项是：

  • 手动删除 @Delegate 注释并生成/手动编码委托代码。如果您在注释中使用属性，这会有点困难。
  • Delombok 具有以下内容的文件 @Delegate 注释，也许可以添加回您想要的注释。
  • 切勿更新 Lombok 或维护分叉（或使用体验式功能）。
  • Delombok 整个项目并停止使用 Lombok。

据我所知， Delombok 没有删除注释子集的选项;至少对于单个文件的上下文来说，要么全部要么全无。我打开了 请求此功能的票证 带有 Delombok 标志，但我不希望在不久的将来出现这种情况。

更新 8（2014 年 10 月 20 日）
如果您可以选择，Groovy 提供了 Lombok 的大部分相同优点，以及大量其他功能，包括 @代表. 。如果您认为很难将这个想法推销给当权者，请查看 @CompileStatic 或者 @TypeChecked 注释看看是否可以帮助您的事业。实际上， Groovy 2.0 版本的主要关注点是静态安全.

更新 9（2015 年 9 月 1 日）
龙目岛仍处于 积极维护和增强, ，这预示着采用的安全水平。这 @Builder 注释是我最喜欢的新功能之一。

更新 10（2015 年 11 月 17 日）
这似乎与OP的问题没有直接关系，但值得分享。如果您正在寻找工具来帮助您减少编写的样板代码量，您还可以查看 谷歌汽车 - 尤其 自动值. 。如果你看看他们的 幻灯片, ，将 Lombok 列为他们试图解决的问题的可能解决方案。他们列出的龙目岛缺点是：

  • 插入的代码是不可见的（你无法“看到”它生成的方法）[编者注 - 实际上你可以，但它只需要一个反编译器]
  • 编译器 hack 是非标准且脆弱的
  • “在我们看来，你的代码不再是真正的 Java”

我不确定我在多大程度上同意他们的评价。鉴于幻灯片中记录的 AutoValue 的缺点，我将坚持使用 Lombok（如果 Groovy 不是一个选项）。

更新 11（2016 年 2 月 8 日）
我发现 春罗 有一些 相似的注释. 。我有点惊讶地发现 Roo 仍然是一个东西，而且查找注释文档有点粗糙。移除看起来也不像 de-lombok 那么容易。龙目岛似乎是更安全的选择。

更新 12（2016 年 2 月 17 日）
在试图找出为什么在我目前正在进行的项目中引入 Lombok 是安全的理由时，我发现了一块金子，其中添加了 v1.14 - 这 配置系统！这意味着您可以配置项目以禁止您的团队认为不安全或不需要的某些功能。更好的是，它还可以使用不同的设置创建特定于目录的配置。这太棒了。

更新 13（2016 年 10 月 4 日）
如果这种事情对你来说很重要 奥利弗·吉尔克 觉得很安全 将 Lombok 添加到 Spring Data Rest.

更新 14（2017 年 9 月 26 日）
正如所指出的 @gavenkoa 在对OP问题的评论中， JDK9 编译器支持尚不可用 （问题＃985）。对于 Lombok 团队来说，这听起来也不是一个容易解决的问题。

更新 15（2018 年 3 月 26 日）
Lombok 变更日志显示自 v1.16.20 起“现在可以在 JDK1.9 上编译 lombok“ 虽然 #985 仍然开放。

然而，为了适应 JDK9，需要进行一些重大更改；所有这些都与配置默认值的更改无关。有点令人担忧的是，他们引入了重大更改，但该版本仅增加了“增量”版本号（从 v1.16.18 到 v1.16.20）。由于这篇文章是关于安全的，如果您有 yarn/npm 就像自动升级到最新增量版本的构建系统一样，您可能会猛然醒悟。

更新 16（2019 年 1 月 9 日）

它似乎 JDK9问题已经解决 据我所知，Lombok 可以与 JDK10 配合使用，甚至可以与 JDK11 配合使用。

我注意到的一件事是，从安全方面来看，从 v1.18.2 到 v1.18.4 的更改日志列出了两项： BREAKING CHANGE！？我不确定 semver“补丁”更新中如何发生重大变化。如果您使用自动更新补丁版本的工具，则可能会出现问题。

继续使用龙目岛，您可以根据需要“delombok”你的代码之后 http://projectlombok.org/features/delombok html的

个人（和主观因此）我发现，使用相对于IDE时，龙目岛，使我的代码更具表现什么，我试图实现/错综复杂的方法，如散列码与自己平等的实现。

当使用

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

这是更容易保持的Equals和一致的hashCode和跟踪哪些领域进行评估，比任何IDE /自己的实现。这是尤其如此，当你还在添加/删除定期领域。

这同样适用于所述@ToString注释和它的参数，其清楚地传达关于包括/排除字段，吸气剂或字段的访问和阉羊或不呼叫super.toString()使用所需的行为。

和再次通过注释的整个类@Getter或@Setter(AccessLevel.NONE)（以及任选的覆盖任何发散方法）它立即清除方法将可用于所述字段的内容。

在利益去和..

在我的脑海里是不是减少了代码，而是清楚地传达你的愿望实现的目标，而不是从的Javadoc或实现看着办吧。减小的代码只是可以更容易地发现任何发散-方法实现。

Lombok的是很大的，但...

Lombok的打破注释处理的规则，因为它不产生新的源文件。存在它不能与另一个注释处理器，如果他们期望getter / setter方法或使用任何其他这种装置。

在一系列轮注释处理运行。在每一轮，每个人得到一个轮到运行。如果轮结束后发现任何新的Java文件，新一轮的开始。通过这种方式，注释处理器的顺序并不重要，如果他们只生成新的文件。由于龙目不产生任何新的文件，没有新一轮的开始，所以不能按预期运行某些AP依赖于龙目岛的代码。这是一个巨大的痛苦，我的来源，而使用mapstruct，并且因为它破坏了你的日志行号delombok-ING是不是一个有用的选项。

我最终砍死构建脚本工作既龙目岛和mapstruct。但我想砸龙目岛因如何哈克是 - 至少在这个项目。我用Lombok的所有的时间在其他的东西。

我读到了一些关于 Lombok 的意见，实际上我正在一些项目中使用它。

嗯，第一次接触Lombok我就留下了不好的印象。几周后，我开始喜欢它。但几个月后，我在使用它时发现了很多小问题。所以，我对龙目岛的最终印象并不是那么积极。

我这样思考的理由是：

  • IDE插件依赖. 。Lombok 的 IDE 支持是通过插件实现的。即使在大部分时间工作得很好，你也始终是这个插件的人质，需要在 IDE 的未来版本中维护， 甚至语言版本 （Java 10+将加速该语言的发展）。例如，我尝试从 Intellij IDE 2017.3 更新到 2018.1，但我无法执行此操作，因为实际的 lombok 插件版本存在一些问题，我需要等待插件更新...如果您想使用不支持任何 Lombok 插件的更具替代性的 IDE，这也是一个问题。
  • “查找用法”问题。. 。使用 Lombok，您看不到生成的 getter、setter、构造函数、构建器方法等。因此，如果您打算找出 IDE 在您的项目中使用了哪些方法，则不能仅查找拥有此隐藏方法的类。
  • 如此简单以至于开发人员不关心破坏封装. 。我知道这对于龙目岛来说并不是真正的问题。但我看到开发人员不再控制哪些方法需要可见或不可见的更大趋势。所以很多时候他们只是复制粘贴 @Getter @Setter @Builder @AllArgsConstructor @NoArgsConstructor 注释而不考虑类真正需要公开哪些方法。
  • 对建造者的痴迷 ©。我发明了这个名字（马丁·福勒，下车）。开玩笑吧，创建构建器非常容易，即使一个类只有两个参数，开发人员也更喜欢使用 @Builder 而不是构造函数或静态构造函数方法。有时他们甚至尝试在 lombok Builder 中创建一个 Builder，从而造成奇怪的情况，例如 MyClass.builder().name("Name").build().create().
  • 重构时的障碍. 。例如，如果您正在使用 @AllArgsConstructor 并且需要在构造函数上添加一个参数，IDE 无法帮助您在实例化该类的所有位置（主要是测试）添加这一额外参数。
  • 用具体方法混合龙目岛. 。您不能在所有场景中使用 Lombok 来创建 getter/setter/等。因此，您将看到这两种方法混合在您的代码中。一段时间后你就会习惯这一点，但感觉就像是对这门语言的黑客攻击。

正如另一个答案所说，如果您对 Java 的冗长感到愤怒并使用 Lombok 来处理它，请尝试 Kotlin。

我知道我迟到了，但我无法抗拒的诱惑：有人喜欢龙目也应该看看斯卡拉。许多您在龙目岛寻找好的想法是Scala语言的一部分。

在你的问题：它肯定更容易得到你的开发人员试图龙目岛比斯卡拉。试试看，如果他们喜欢它，尝试斯卡拉。

正如免责声明：我像Java，太

我在龙目岛的使用几乎所有我的项目为一年，但不幸的是删除它。在开始的时候是发展，但建立新的团队成员发展环境的一个非常干净的方式是不是很容易和简单。当它成为一个头痛我只是删除它。但它是一个良好的工作和需要更多的简单性设置。

当我向我的团队展示该项目时，热情很高，所以我认为你不应该害怕团队的回应。

  • 就投资回报率而言，它的集成非常简单，并且不需要更改其基本形式的代码。（只需向您的类添加一个注释）

  • 最后，如果你改变主意，你可以运行 unlombok，或者让你的 IDE 创建这些 setter、getter 和 ctor，（我认为一旦他们看到你的 pojo 变得多么清晰，就没有人会要求这样做）

想用龙目岛的@ToString但很快就项目面临随机的编译错误，在IntelliJ IDEA的重建。只好打编译前几次增量编译可以成功完成。

尝试都Lombok的1.12.2和0.9.3与IntelliJ IDEA的12.1.6和13.0无任何插件Lombok的下JDK 1.6.0_39和1.6.0_45。

不得不从delomboked源手动复制生成的方法，并把Lombok的搁置，直到更好倍。

<强>更新

在问题发生仅启用并行编译。

提起的问题： https://github.com/rzwitserloot/lombok/issues/648

<强>更新

  

mplushnikov评论01月30 2016

     

的Intellij的较新的版本   没有这样的问题了。我认为它可以在这里关闭。

<强>更新

我会强烈如果可能建议从Java + Lombok的开关科特林。 因为已经从地上爬起来所有的Java问题，龙目岛试图解决解决。

我对 Lombok 的看法是，它仅仅提供了编写样板 Java 代码的快捷方式。
当谈到使用快捷方式编写样板Java代码时，我会依赖IDE提供的这些功能——就像在Eclipse中一样，我们可以进入菜单“Source”>“Generate Getters and Setters”来生成getter和setter。
我不会依赖像 Lombok 这样的库：

  1. 它会用替代语法的间接层污染您的代码（请阅读 @Getter, @Setter, ， ETC。注释）。我不会学习 Java 的替代语法，而是切换到任何其他本地提供类似 Lombok 语法的语言。
  2. Lombok 需要使用 Lombok 支持的 IDE 来处理您的代码。这种依赖性给任何重要的项目带来了相当大的风险。开源 Lombok 项目是否有足够的资源来继续为各种可用 Java IDE 的不同版本提供支持？
  3. 开源 Lombok 项目是否有足够的资源来继续为未来即将推出的较新版本的 Java 提供支持？
  4. 我还感到紧张的是，Lombok 可能会引入与运行时与字节代码一起使用的广泛使用的框架/库（如 Spring、Hibernate、Jackson、JUnit、Mockito）的兼容性问题。

总而言之，我不喜欢用 Lombok 来“调味”我的 Java。

我也遇到过是龙目岛和杰克逊CSV 后，当我marshalized我的对象（的java bean）为CSV文件，列在那里复制，然后我删除龙目岛的一个问题@Data注释和marshalizing正常工作。

我不推荐它。我用它，但后来当我与NetBeans 7.4工作有人搞乱我的代码。我已经删除龙目岛中的所有文件在我的项目。有delombok，但我怎么能肯定它不会拧我的代码。我得花几天刚刚删除龙目岛，回到普通的Java风格。我只是太辣...

我还没有使用龙目岛还没试过 - 这是/是我名单上的下一个，但它听起来好像Java的8造成显著的问题吧，和善后工作仍在进行中作为一个星期前。我该源是 https://code.google.com/p/ projectlombok /问题/细节？ID = 451 。

许可以下： CC-BY-SA 和 归因
不隶属于 StackOverflow
scroll top