Project Lombok有哪些风险？

Question

我想出了新的一年的性能目标，并且我认为我的目标是减少代码库的大小，特别是样板，我会觉得很有趣。我提出的解决这个问题的一个动作是使用Project Lombok来使豆子尽可能短。但我习惯于忽视新软件和方法的缺点，所以我依赖Stack Overflow社区：谁能告诉我为什么龙目岛是一个坏主意？

Answer 1

Lombok的一个限制是它与java编译器密切相关。由于注释处理器API仅允许在编译期间创建新文件（而不是现有文件的修改），因此lombok使用该API作为修改java编译器的入口点。不幸的是，编译器的这些修改会大量使用非公共API。使用lombok可能是一个好主意，但你必须意识到升级你的编译器可能会破坏你的代码。概率很低，但我总是觉得使用非公共API感到不舒服。

Answer 2

主要的缺点是IDE支持。由于Lombok实际上并不是一种语言更改，并且由于您的IDE只能理解java，因此您需要一个支持Lombok的IDE才能使其正常工作。截至目前，仅包含Eclipse和IntelliJ的Eclipse 。如果您使用可能没问题的eclipse，但请记住您也在为未来的开发人员做出决定。

我建议你考虑将你的一些代码转换成一种不那么礼仪的语言，比如groovy。我们已经成功地将我们的一些业务逻辑和模型转变为groovy，并且它的工作非常顺利。

Answer 3

像Lombok这样的东西的一个潜在缺点是，由于setter / getters“缺失”，源工具可能无法“识别”生成对象的方面，从而赋予它“bean”特性，因为这些特性仅在编译类中显示

另一个缺点是它是工具链中的另一个“黑魔法”。幸运的是，它似乎是一个相当温和的部分（我没有使用它），它发生在编译时而不是运行时的事实实际上是一种祝福（恕我直言）。但是，如果没有项目，您将无法重用或共享代码，因为它会在您的代码库中添加工件。因此，虽然编译的类文件可能是“POJO”，但我认为您的源代码不是POJO。

这些都不是严重的缺点，而只是需要注意展望的方面。

Answer 4

在我看来，＆＃34; Java + Lombok＆＃34;不再是Java源代码了。我认为这是Borland公司多年前在他们用于VCL的Borland C ++ Builder IDE中所做的类似的事情 - 他们介绍了＆＃34;属性＆＃34;在C ++代码中有效地引入了某种不再是C ++的新编程语言（而不是C ++标准的C ++语言）。来源使用＆＃34; Java + Lombok＆＃34;在Java语言规范方面，它们不是有效的来源。此外，我认为注释并非旨在影响语言语义。

Answer 5

它是第三方图书馆，有些开发人员对此并不了解。

IDE应该支持注释处理（有IDEA和Eclipse的插件）。

如上所述，您的代码将没有getter / setter。它导致声纳/检查式违规。

Answer 6

正如用户@Jcs在另一个答案中指出的那样，我想补充更多。

在我们的项目中，我们使用了用于生成映射器类的mapstruct，在编译代码之前，使用mvn generate-sources命令，这是在使用maven处理器插件的过程阶段完成的。

项目lombok在编译阶段在类文件中添加getter / setter的字节码。

由于在编译之前执行了进程阶段，因此它发现类中没有可用的getter / setter。

有一些变通方法可以执行多个编译阶段。 有关详细信息，请参阅此git hub ticket。

注意：我正在使用Spring的STS ide，它受lombok支持：）

Answer 7

我认为，Lombok项目最明显的风险是，当您决定使用lombok时，您还决定与代码打交道的其他所有人都使用lombok。这对所有库来说都是正确的说法，但是Lombok的特殊之处在于它是一个构建时依赖项，您的IDE需要使用插件来确定发生了什么。这意味着任何有理由触摸您的代码的人。尝试调试怪异行为等的人）需要知道如何设置它以及它如何工作。这可能有点令人沮丧。

Answer 8

添加到其他回复中。

不使用它的主要原因是在 Java 14 中作为实验性功能添加了一个新的 record 关键字。Java 16 将 records 带出预览版，这将使 Lombok 项目在大多数情况下过时。

自 Java 14 以来，可以编写：

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

无需任何注释即可自动访问构造函数、getter/setter、hashCode、equals 和 toString 方法。