logo标签列表

使用Project Lombok有哪些风险？

javajakarta-eeboilerplatelombok
54

我正在制定新年度的绩效目标，想把减少代码库大小，特别是样板代码作为一个目标。我想采取的一种方法是使用Project Lombok来使JavaBean变得更短小精悍。但是我有忽视新软件和方法缺点的习惯，所以我依赖于Stack Overflow社区：有人能告诉我为什么Lombok不是个好主意吗？

2
可能是使用Project Lombok安全吗？的重复。 - Dherik
也许有趣：https://medium.com/@gabor.liptak/some-dangers-of-using-lombok-d759fc8f701f - Gábor Lipták
2
https://artofcode.wordpress.com/2018/12/18/dont-use-lombok/ - Mayur
8个回答
43

Lombok的一个限制是它与Java编译器紧密耦合。由于注解处理器API只允许在编译期间创建新文件（而不是修改现有文件），因此Lombok使用该API作为修改Java编译器的入口点。不幸的是，这些对编译器的修改大量使用了非公共API。使用Lombok可能是个好主意，但您必须意识到升级编译器可能会破坏您的代码。这种情况发生的概率很低，但我总是感到使用非公共API让人感到不舒服。

13
非常好的观点。Java 8 + Lombok 的历史向我们展示了这可能是一个问题。 - G. Demecki
2
目前，他们已经修复了它，并且可以在Java 9上运行，但尚不能在Java 10上运行。 - Whiteship
32

在我看来，“Java + Lombok”中的源代码不再是Java源代码了。我认为这与Borland公司多年前在其Borland C++ Builder IDE for VCL中引入“属性”类似，实际上引入了一种新的编程语言，它不再是C++（不再符合C++语言标准）。使用“Java + Lombok”的源代码不符合Java语言规范的要求。此外，我认为注释并不是用来影响语言语义的。

我同意这个答案比被接受的更好。Lombok不再限制IDE的使用。它只是将Java带入了现代化的时代。如果没有Lombok，我会为我的公司大声疾呼，要求将代码库更改为像Kotlin这样不那么冗长的东西。 - Guilherme Taffarel Bergamin
2
希望有了Java 21，更少的人会对龙目岛感兴趣。 - undefined
24

一个主要的缺点是IDE支持。由于Lombok实际上并不是一种语言更改，且你的IDE仅能理解Java，因此你需要一个支持Lombok的IDE才能使事情正常运行。截至目前，只有Eclipse包括Eclipse和IntelliJ支持。如果你使用Eclipse也许还可以，但请记住，你也在为未来的开发人员做出决策。

我建议你考虑将部分代码移入到一种较少仪式化的语言，例如Groovy中。我们已经成功地将一些业务逻辑和模型移入Groovy中，并且它工作得非常顺畅。

6
错了，不只是在 Eclipse 中可以使用：我在 Netbeans Dev 中使用 Project Lombok 没有问题。而且我认为它们也支持其他 IDE。 - TheLQ
17
此回答已过时。IntelliJ（通过插件）和NetBeans都支持Lombok。 - kctang
一个相关的问题：“使用Project Lombok安全吗？” https://dev59.com/gW865IYBdhLWcg3wYNVS - Snekse
1
更新2021年最新版的Intellij Idea从2020.3开始支持lombok。我不再觉得这是IDE的问题了。只要团队中的每个人都同意使用Lombok，它只会帮助加快开发时间，如果团队中的每个人都想做他们想做的事情，并且没有关于应该是“团队标准”的共识，那么它可能会减慢开发时间。 - GauravEdekar
1
你需要一个IDE支持的事实对我来说表明Lombok是一种反模式。 - dieter
显示剩余2条评论
24
使用类似Lombok这样的工具的一个潜在缺点是，由于缺少setter/getter方法，源代码工具可能无法“识别”生成对象的某些方面，这些方面仅在编译后的类中体现出“bean”的特性。
另一个缺点是它是工具链中的又一个“黑魔法”部分。幸运的是，它似乎是一个相当良性的组件（我没有使用过），并且它发生在编译时而不是运行时，实际上是一种福音（在我看来）。但是，由于它向您的代码库添加了构件，因此您将无法重用或共享项目之外的代码。因此，虽然编译后的类文件可能是一个“POJO”，但我认为您的源代码不是一个“POJO”。
这些都不是致命的缺点，而只是需要注意的方面。
6
你可以使用 http://projectlombok.org/features/delombok.html 来获取原始类。 - maaartinus
2
我完全同意“黑魔法”这个术语。如果你熟悉它，那么你就知道发生了什么，但如果你是新手，那么它看起来像是你的代码在欺骗你，可能会导致一些让人摸不着头脑的时刻。 - DanDan
6

在我看来，使用 Project Lombok 最明显的风险是，当你决定使用 lombok 时，你也决定了其他所有处理你的代码的人也要使用 lombok。这对所有库都是适用的真实情况，但 Lombok 是特殊的，因为它是一个构建时依赖项，你的 IDE 需要插件才能弄清楚发生了什么。这意味着任何有理由接触你的代码的人，例如试图调试奇怪行为等人，都需要知道如何设置并了解它的工作原理。这可能会有点令人沮丧。

2
非常正确。这尤其适用于那些来自不同编程背景的人，特别是那些使用非JVM语言的人，因为在这些语言中，lombok的知名度要低得多。 - A248
6

这是一个第三方库，有些开发人员并不熟悉它。

IDE应该支持注解处理（在IDEA和Eclipse中有插件可用）。

如上所述，您的代码将没有getter/setter。 这会导致sonar/checkstyle违规。

已经有记录的方法可以解决这个问题 - 在运行Sonar/Checkstyle之前使用delombok。 但是，无论如何，您真的想在您的POJO上进行代码覆盖率吗？！ - Ali H
这不是关于POJO覆盖率的问题。Sonar建议“将此字段设置为私有并添加getter方法”。 - dehasi
6

补充其他回答的内容。

不使用它的主要原因是Java 14中添加了一个名为record的实验性功能。Java 16将records从预览版中释放出来，这将使大多数情况下项目Lombok变得过时。

自Java 14以来，人们可以编写：

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

这将自动提供构造函数、getter/setter、hashCode、equals和toString方法，无需任何注释。

4
记录类不允许继承，也没有设置器。此外，一旦您实例化它，就无法更改其状态。 - Philippe Gioseffi
在几乎所有情况下，这些限制都是好事。然而，由于这些限制，record并不是lombok的完全替代品，除非可能是特定于@lombok.Value。即便如此，它们之间仍然存在一些差异。 - undefined
5
正如用户@Jcs在另一个答案中指出的那样，我想再补充一些内容。
在我们的项目中，我们使用mapstruct来生成映射器类，在代码编译之前使用mvn generate-sources命令，在处理阶段使用maven processor插件完成此操作。
项目lombok在编译阶段向类文件中添加了getter/setter的字节码。
由于处理阶段在编译之前执行，因此它发现类中没有可用的getter/setter。
有一些解决方法可以执行多个编译阶段。有关更多详细信息，请参见git hub ticket。
注意：我正在使用Spring的STS ide，并且它支持lombok :)
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接