Project Lombok有哪些风险？

Question

我想出了新的一年的性能目标,我认为我的目标是减少代码库的大小,特别是样板,我会觉得很有趣.我提出的解决这个问题的一个动作就是使用Project Lombok来使bean尽可能短.但我习惯于忽视新软件和方法的缺点,所以我依赖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

在我看来,"Java + Lombok"中的源代码不再是Java源代码.我认为这是Borland公司多年前在他们用于VCL的Borland C++ Builder IDE中所做的类似的东西 - 他们在C++代码中引入了"属性",有效地引入了某种不再是C++的新编程语言(不是C++意义上的C++) C++语言标准).使用"Java + Lombok"的源在Java语言规范方面不是有效的源.此外,我认为注释并非旨在影响语言语义.

Answer 5

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

Answer 6

添加到其他回复。

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

从 Java 14 开始，人们能够编写：

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

它可以自动访问构造函数、getters/setter、hashCode、equals 和 toString 方法，而无需任何注释。

Answer 7

正如用户@Jcs在另一个答案中指出的，我想添加更多内容。

在我们的项目中，我们使用 mapstruct 来生成映射器类，在编译代码之前，使用 mvngenerate-sources 命令，这是在处理阶段使用 Maven 处理器插件完成的。

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

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

有一些解决方法可用于执行多个编译阶段。有关更多详细信息，请参阅此git hub 票证。

注意：我使用 Spring 的 STS ide，并且它受 lombok 支持:)

Answer 8

这是一个第三方库，有些开发人员对此不太了解。

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

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